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REMOTIMG GENERAL PURPOSE OPERATING SYSTEM SERVICES VIA A 
PEER NETWORKING DEVICE CONTROL PROTOCOL 

TECHNICAL FIELD 

This Invention relates generally to remote access to and control o! 
8 general purpose operating system sewtees, and more particularly to 
remoting such services via a peer networking device control protocol. 

BACK6ROUN0 AND SUMMARY 

Present day, general purpose operating systems provide numerous 
services for use by application programs. An operating system Is software 

1 0 that generally controls the allocation and usage of hardware resources on a 
computer, such as memory., central processing unit {CPU) time, disk space, 
sod peripheral devices. General purpose operating systems provide an 
operating platform or environment on which application software for a wide 
variety of purposes can be run, Examples of popular general purpose 

I S operating systems include Microsoft Windows operating systems (e.g., 
Windows 85, 98, NT, 2000}; the Mac OS of Apple Computer, inc.; UNIX 
or Linux available from various vendors; and BeOS from Be, Inc. 

A service has generally been defined to be a program, routine, or 
process that performs a specific system function to support other 

20 programs, particularly at a low (close to the hardware! level. Typically 
although not necessarily, the services do not provide a user interface (till 
or interact directly with the user (e.g., display messages m a window or 
dialog box, or receive input from keyboard or mouse! during normal 
processing (except error messages and like interaction when exceptions 

25 occur, and administration or configuration of the service), but instead 
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typically operate under programmatic control of an application program 
with which the user directly interacts* Examples of services provided In 
the Microsoft Windows' 5 operating systems include date and time clock, file 
and primer sharing, print spooling, electronic mail, fax, telephony, file 
8 synchronization le<g., with mobile- devices}, file backup and archiving,, audio 
and video file streaming (e.g., to a peripheral play-back device, such as 
speakers or a monitor), audio and video codecs,, file 

compression/decompression,, problem diagnosis and support, event logging, 
user and software configuration administration, security and access 

10 control, remote access IRAS), networking {Internet socket, FTP, HTTP, 

TCP/IP, NetBIOS, etc.), name and address IDHCP, DNS), remote procedure 
call (RPC) end named pipe, dynamic peripheral configuration (Plug and 
Play}, and application scheduling te.g., Windows 95 system agent), among 
others. In addition to the services provided with an operating system by its 

1 6 vendor, some operating systems {e.g.,. Microsoft Windows NT) also 
support an extendible services architecture that permits plugging in or 
installing later-developed services {e.g., Windows NT Services, Unix 
Daemon). 

Operating system services typically are exposed for programmatic 
20 control and use by locally executing application programs through an 
application programming interface {API) of the operating system, The 
application program typically provides a user Interface with which the user 
interacts to effect application-specific task work, The application program 
may utilize the operating system services, and programmaticallv controls 
26 the services through the APIs. For example, a "music jukebox" application 
program could provide a user interface having a "graphics equalizer" and 
"playlist" display, and start, stop and pause controls with which the user 
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interacts to play music audio files. The application program,, in turn, 
utilizes audio streaming services of the operating system, which the 
application program controls via an API The operating system API 
typically operates using a focal procedure call, software interrupt, or like 
8 mechanism. 

Present industry trends (e.g., rapidly decreasing costs of computing 
and networking technologies) are leading towards embedding computing 
and networking capabilities into the design of many specific-purpose 
devices in the home, office and public places. Examples include digital 

10 cameras.: audio/video receivers, recorders and players; printers; home 
appliances; lighting systems; heating, ventilation and air-conditioning 
(HVAC) equipment; security systems; teiephony equipment; end etc. The 
combination of inexpensive- and reliable shared networking media with a 
new class of small computing devices has created an opportunity for new 

I B functionality based mainly on the connectivity among these devices. This 
connectivity can he used to remotely control devices, to move digital data 
in the form of audio, video and still images between devices, to share 
information among devices and with the Internet and to exchange 
structured and secure digifai data to support things like electronic 

20 commerce. The connectivity also enables many new applications for 
computing devices, such as proximity-based usage scenarios where 
devices Interact based at least in part on geographical or other notions of 
proximity- These developments are occurring at the same time as more 
people are becoming connected to the internet and as connectivity 

25 solutions are falling in price and Increasing in speed. These trends appear 
to lead towards a world of ubiquitous and pervasive networked computing, 
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where computing and networking are. bulk into .all types of devices In the 
user's home, work and public environments. 

With pervasive networked computing, the general use scenario 
changes from one where the user interacts directly with a device that 
5 performs some work (e.g., by pressing buttons on a control panel), to one 
where the user interacts with one device that provides user interactivity 
and remotely controls another device doing the work. For example, the 
user directly interacts with a universal remote controller,, call phone or 
handheld/palm top/tablet computer to operationally control other devices in 

10 their Immediate environment, such as a vending machine,, video monitor, 
printer, door opener, or etc. 

Recently, several peer networking device control protocols have bean 
introduced to support this new remote control use scenario expected to 
become typical of pervasive computing. These include the Home Audio 

1 5 Video Interoperability (HAVi) protocol developed by the Havi Organisation 
(formed by Grundig AG, Hitachi, Ltd., Matsushita Electric industrial Co... 
Ltd, (Panasonic), Royal Philips Electronics,. Sharp Corp., Sony Corp... 
Thomson Multimedia and Toshiba Corp); the JIN! protocol developed by 
Sun Microsystems, Inc.; and the Universal Plug and Play {UPnP) protocol of 

20 the UPnP Forum and Microsoft Corporation. In general, these peer 
networking device control protocols are designed to allow devices to 
expose their operational functionality to remote control from devices 
diteouy ope? a ted by a user. 

As discussed above, general purpose operating systems provide a 

25 rich set of services to application programs running on the operating 
system via locally accessible APIs, in pervasive computing, peer 
networking device control protocols allow remote control of operational 
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functionality of typically specific purpose devices, it would generally be 
advantageous to also remotely control the general purpose operating 
system services in pervasive computing environments. However,, because 
the services are programmed to be exposed through the operating system 
5 APIs and not via peer networking device control protocols, the services are 
not available to user control devices through these protocols, 

in the UPnP protocol, legacy peripheral devices |e.g., scanner,, 
printers,, date storage drives,, etc. I connected to a host computer can be 
exposed for remote control from a "user control point" device via a "UPnP 

10 bridge," which acts as a converter or adapter between the UPnP peer 
networking connectivity protocol and a host-peripheral connectivity 
protocol The UPnP hrid<}e generaliy runs on the host computer acting as a 
* rolled device In place of a "\ i | 

addressing, discovery, description, and control messaging in the UPnP 

1 5 protocol from user control point devices., and in turn interacts accordingly 
with the bridged peripheral device using the bridged peripheral's host- 
peripheral connectivity protocol. Again however, because general purpose 
operating system services are programmed to be exposed through 
operating system APIs, the services are not available to remote control via 

20 a UPnP bridge to a host-peripheral connectivity protocol. 

The present invention provides a way to expose general purpose 
operating system services to remote control via a peer networking device 
control protocol, which allows rouse of the operating system service 
without repfogrammlng the service as a ■"controlled device" per the peer 

25 networking device control protocol. In accordance with the invention, an 
adapter runs on the genera! purpose operating system and converts 
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between the peer networking device control protocol and operating system 
APIs, so as to remote the general purpose operating system's services. 

in an implementation of the invention described herein, the adapter 
Includes a publishing service and a service remoter. The service remoter 
6 operates to remote operational functionality of general purpose operating 
system services through the publishing service. The publishing service 
supports a publishing API via which application programs running on the 
operating system as weii as the service remoter can interact with the 
publishing service. The publishing service operates to expose operational 

1 0 functionality of the application programs and the services that interact with 
the publishing service through the publishing API as "controlled devices" 
under the pear networking device control protocol. The publishing service 
acts as ihe^eontroilad devices" per the peer networking device control 
protocol by appropriately responding on behalf of the rerouted applications 

1 5 and services to addressing, discovery, description and control requests 
made by user control point devices in the peer networking device control 
protocol The publishing service further converts these peer networking 
device control protocol requests to causa appropriate controlled operation 
of the services through the service remoter., which in turn interacts directly 

20 with the services through their APIs to effect the controlled operation. 

Additional features and advantages will be made apparent from the 
following detailed description of the illustrated embodiment which proceeds 
with ret ere? \ drawings 

BRIEF DESCRIPTION OP TH6 DRAWINGS 

25 figures 1 and 2 are block diagrams of a device architecture par 

Universal Plug and Piay using user control points, controlled devices., 
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bridges, and service remoter/publisher for connectivity between devices 
and services. 

figure 3ssa block diagram of a general purpose operating system 
architecture with service remoter/publisher for remotmg operating system 
S services per Universal Plug and Ray in accordance with an Implementation 
of the invention. 

Figure 4 Is a block diagram of an implementation of the service 
remoter/publisher of Figure 3 in the Microsoft Windows operating system 
architecture, 

1 0 Figure 5 is a block diagram of a device model per Universal Rug and 

Ray, 

Figure 6 is a block diagram illustrating example devices conforming 
to the device model of Figure S, 

Figure 7 is a block diagram Illustrating device state synchronization 
1 8 using a state table and eventing. 

Figure 8 is a block diagram Illustrating device addressing. 
Figure 9 is a block diagram of a programmatic irvterf ace-to-nefwotk 
massaging a&dpter or Rehydrator in the device control mode! of Figure 5. 
Figure 1 0 is a general data flow diagram of the Rehydrator of Figure 
20 9 in the device control model of Figure 5, 

Figure 1 1 is a block diagram of an Implementation design of the 
Rehydrator of Figure 9, 

Figures 12 and 13 are block diagrams illustrating an internal software 
architecture of the user control point and controlled device in the device 
25 control model of Figure 5. 
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Figure 14 is a block diagram illustrating an interna! software 
architecture of a combined bridge and user control point in the device 
control model of Figure 8, 

Figure 1 6 is a data flow diagram illustrating a typical browsing 
S protocol sequence in the device control model of Figure 5, 

Figure IS is a listing showing a layout of a description document in 
the device control model of Figure 5. 

Figure 17 m a listing of an exemplary icon list of a Description 
Document in the device control model of Figure 5. 
1 0 Figure 1 8 is a listing of an exemplary service control protocol 

declaration in a Description Document in the device control model of Figure 
5, 

Figures 1 9 and 20 are a listing of an XML schema for a Service 
Control Protocol Declaration Language used In the device control model of 
18 Figured. 

Figure 21 is a block diagram of an eventing mode! used In the device 
control mode! of Figure 5, 

Figure 22 is a data flow diagram Illustrating subscription, notification 
and unsubscription in the eventing model of Figure 21 . 
20 Figure 23 is a block diagram of a computer system that may be used 

in the device control model of Figure §\ 

Figure 24 is a block diagram of a device having embedded computing 
and networking capability par universaFplug-end-piay fUPnP) standards that 
may be used in combination with the computer system of Figure 23 in the 
2S device control model of Figure §< 

F-gum 25 is a block diagram of a software arch! lecture per UPnP 
standards in the embedded computing device of Figure 24 
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Figure 26 is a data flow diagram of s process for automatic network 
introduction of the embedded computing device of Figure 24 Into an ad hoc 
computer network, environment per the UPnP protocol 

Figure 27 Is a date flow diagram of a process for automatic network 
5 introduction of the embedded computing device of Figure 24 into a 
configured computer network environment per the UPnF protocol 

Figure 28 Is a block diagram of a software architecture of a client 
device per UPnP standards having embedded computing and networking 
capability that may be used in the device control model of Figure S, 
10 Figure 29 is a block diagram of an exemplary home or office 

pervasive computing environment having a variety of computers as per 
Figure 23 and embedded computing devices as per Figure 24 
Interconnected per UPnP standards thai may be used in the device control 
model of Figure 5, 

1 S Figures 30 through 40 are program listings of Interfaces used m the 

Behydrator implementation design of Figure 1 1 , 

Figure 41 is a flow diagram illustrating automatically installing and 
configuring a UPnP bridge upon attaching or connecting a peripheral on a 
host personal computer. 




The following detailed description is directed toward adapting 
general purpose operating system {OS} services for operation within a 
distributed device control model having peer networking connectivity. In 
25 one described implementation, this OS servlce-to-peer networking control 
protocol adapter is used in a device architecture 100 (Figure 1), 
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connectivity model, and device control protocol proposed by Microsoft 
Corporation, called Universal Plug and Play {Wop*}. 

U iversal I lug >u i Play 

Universal Plug and Play fUPnP) Is an open network architecture that 
8 is designed to enable simple, ad hoc communication among distributed 
d©vicss and services from many vendors. UPnF leverages internet 
technology and can be thought of as an extension of the Web model of 
mobile Web browsers talking to fixed Web servers to the world of peer-to- 
peer connectivity among mobile end fixed devices. UPnP embraces the 

10 aero configuration mantra of Plug and Play CPnP) but is not a simple 
extension of the PnP host/peripheral model* 

The cost, she and battery consumption of computing technology- 
including processing, storage and displays-continues to fail This trend is 
enabling the evolution of stand-alone, single or limited function computing 

1 § devices such as digital cameras, audio playback devices,, smart mobile 
phones and handheld computers. Concurrent with this, the economical 
storage and transmission of digital audio, video and still Images is enabling 
highly flexible models for managing entertainment content, 

While many of these devices are capable of useful stand-alone 

20 operation, seamless connectivity with the PC can enhance the value to the 
customer of both stand-alone devices and the PC, Good examples of this 
synergy are digital image capture combined with PC image manipulation, 
storage and email transfer/Web publishing and Information synchronisation 
between a PC and a handheld computer or smart mobile phone. 

25 Since many of these devices, and the PC itself, are mobile, a suitable 

communication architecture must enable a highly dynamic connectivity 
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mode! and must enable peer do-pear mteroperabiiity among arbitrary 
combinations of devices. 

The internet has created a widespread awareness of the value of 
simple, universe! communication thai is independent of the underlying 
5 transmission technology and independent of technology from any single 
vendor, 

UPnP makes it possible to initiate and control the transfer of bulk 
data (e.g. flies) or A/V data streams from any device on the network., to 
any device on the network,, under the control of any device on the 
1 0 network, UPnP enables the ad hoc addition or removal of devices on the. 
network, and It enables multiple controlling devices to remain in sync with 
each other. 

UPnP reuses existing protocols and technology whenever possible. 
The transition to this highly connected land correctable) world will not 

1 S occur overnight, UPnP builds on existing Internet protocols, but 

accommodates devices that cannot run the complete UPnP protocol suite, 
UPnP provides an architecture that enables legacy devices to communicate 
with UPnP devices, 

IP internetworking has been chosen as a UPnP baseline due to Its 

20 proven ability to span different physical media, to enable real world multiple 
vendor interoperation and to achieve synergy with the Internet and home 
and office intranets. Internet synergy enables applications such as IP 
telephony, multiple player games, remote control of home automation and 
security..- internet based electronic commerce,, in addition to simple email 

25 and Web browsing, UPnF's scope includes remote control of devices and 
bulk data transfer, and can be easily extended to specify A/V streaming. 



11 



UPnPs media Independence enables a great deal of flexibility in the 
packaging of products, UPoP enables an A/V system to be controlled 
through an A/C power communications technology., while the transmission 
of A/V streams among the components is analog or digital, One of the 
S controllers of this system could be on the television., while another Is on a 
PC, and yet another connected via radio or infrared. 

Unlike Plug and Play, Universe! Bug and Play is built on top of 
networking and enebies ad hoc gaer-to-peer connectivity, Networking, in 
this context, describes a style of connectivity that enables any networked 

1 0 device to initiate a communication with any other networked device, 

without having established a prior relationship or maintaining a persistent 
relationship between the devices, Networking also allows multiple devices 
to establish one or more connections with a single device, and it allows for 
a device to be capable of both Initiating and accepting connections to/from 

IS other devices. The PnP, or host/peripheral., model is suitable whenever 
there le a persistent relationship between two devices (e.g. a 

keyboard, .mouse and display maintain a persistent relationship with a host 
computer), Evan though networking does not mandate low level persistent 
relationships, it provides the needed anchors {addresses.! for applications to 

20 choose to maintain associations as a convenience for the customer (e.g. 
remembering commonly used networked printers), 

in order to achieve multiple vendor peer-to-peer interoperation among 
devices., vendors desirably agree on common technology and standards up 
to the highest level of desired functional Interoperatiom 

26 UPoP leverages formal protocol contracts to enable peer-to-peer 

intofoperation, Protocols contracts enable real-world multiple-vendor 
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UPnP enables devices to expose a user interface by leveraging 
browser technology. In this context, the browser can be considered to be 
a very rich remote terminal Current, browser technology does not maintain 
a separation of presentation from data, or in the case of devices, control. 
6 It is possible to hunt through a page of HTML to extract data values, but it 
is not convenient or robust. UPnP leverages the separation of presentation 
and data enabled by the use of XML, and if extends this technology to the 
device control domain. 

UPnP provides a device-driven auto-configuration capability that 

10 preserves the experience that customers have on the Web, Today, It is 
possible to navigate around the Web without loading programs beyond the 
browser itself. Since UPnP enables the browser to be extended to control 
devices, and because UPnP devices are controlled with explicit protocols, 
the browser must somehow learn how to talk to UPnP devices. This 

1 8 : learning propose Is driven entirely from the device itself and Is 

accomplishing entirely by uploading an XML document that describes the 
capabilities of the device. The architectural component that enables 
device-driven auto-configuration is ceiled the Rahydrator. The job of the 
Rehydrator is to convert, between APIs and protocols. 

20 Since the auto-cpnfigyratlon process Itself is driven only by the 

exchange of formatted data, there is very little opportunity for e malicious 
attack from a hostile piece of code. 

There are some scenarios where the Web Ul model is not sufficient 
for a rich customer experience, it would not be convenient to have to a 

25 separata Web Ul for each Sight switch In a house. To support a rich user 
Interface and to enable the aggregation of devices into a single UL UPnP 
enables application control in addition to browser control of devices. This 
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is achieved simply by enabling applications to call the same Rehydrator 
APIs that the browser does. Applications can also directly generate and 
consume the raw UPnP control protocol provided they arc not interested 
in the device-driven auto-configuration enabled by the Rehydrator. 
5 UPnP assumes that there will be more than one device with Ui that 

wants to control other devices in any given network., and it provides a 
simple mechanism that enables these control points to remain in syne. 
This mechanism can easily support device front panels and wireless 
remotes that do not run UPnP protocols, The UPnP control model is third- 
1 0 party control; any device can transfer bulk data (e.g. files} or A/V data 
streams from any device on the network, to any device on the network, 
under the control of any device on the network. 

The detailed description that follows uses the terminology defined 

1 8 below. 

Module- A component of a device, software program, or system 
that implements some "functionality",, which can be embodied as software,, 
hardware,, firmware., electronic circuitry, or etc. 

User N , tn 1 set or modules that >n bie ( n lunication 

20 with a UPnP Controlled Device, User Control Points Initiate discovery and 
communication with Controlled Devices, and receive Events from 
Controlled Devices. User Control Points are typically implemented on 
devices that have a user interface. This user interface Is used to Interact 
with Controlled Devices over the network, The modules minimally include 

2S a Discovery Client, a Description Client, a Rehydrator, an Event 

Subscription Client and an Event Sink. User Control Points may also 
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include Visual Navigation, a Web browser and an application execution 
environment. User Control Points cm add value to the network by 
aggregating the control of multiple Controlled Devices (the universal 
remote) or they can implement a function as simple as initiating the 
5 transfer of data to or from a Controlled Device. Examples of devices that 
could be User Control Points are the personal computer (PC),, digital 
television iDTVh set-top box {STB), handheld computer and smart mobile 
phone, and the like. Nothing prevents a single device from implementing 
the functionality of a User Control Point and one or more Controlled 
10 Devices at. the same time. 

Co ntrolled Devi ce. The set of modules that perform certain tasks 
(e.g., printing) and communicate with a User Control Point, Controlled 
Devices respond to discovery requests., accept incoming communications 
from Use? Control Points and may send Events to User Control Points. 

1 5 Devices that support Controlled Device functionality may also support local 
user interfaces such as front panel displays or wireless remotes. The 
modules minimally include a Discovery Server., a Description Server, a 
Control Server,, an Event Subscription Server and an Event Source. 
Controlled Devices may also include a Presentation (e.g., Web) Server. 

.20 Examples of devices that could be Controlled Devices are the VCR, DVD 
player or recorder, heating/ventilatk>n/eir-conditioning equipment. *HVAC), 
lighting controller, audio/video/imaging playback device, handheld 
computer, smart mobile phone and the PC, and the like. Nothing prevents 
a single device from implementing the functionality of a User Control Point 

25 and one or more Controlled Devices at the seme time. 
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leg, A set of modules thai enables Bridged and Legacy Devices 
to interact with native UPnP devices. The bridge itself exposes a collection 
of UPnP Controlled Devices to User Control Points, The Bridge maps 
between native UPnP Device Control Protocols and the underlying protocols 
5 or other control methods exposed by the Bridged and Legacy Devices, 

Optionally,, such a device could expose DPnP Controlled Devices to Legacy 
Devices In the manner required by the Legacy Devices. Nothing prevents a 
single device from Implementing the functionality of a User Control Point, 
one or more Controlled Devices and a Bridge at the same time, 

10 Service Provider,. A module used fey a UPnP Bridge that translates 

between UPnP protocols and the protocols used by Bridged and Legacy 
Devices, m Service Providers are required for communication among 
native UPnP devices. 

Bridged Device, A device that cannot participate in UPnf* at the 
1 B native protocol level, either because the device does not have sufficient 
resources or because the underlying media is unsuitable to run TCP and 
HTTP. Examples of devices that could be Bridged Devices are power line- 
controlled A/V equipment, light switches, thermostats, wristwatchss and 
inexpensive toys, Bridged Devices are UPnP complaint and are exposed to. 
20 other UPnP devices through a UPnP Bridge, 

Legacy Device. Any no^UPnP compliant device that must be 
exposed to other UPnP devices through a UPnP Bridge, 

pJP?Ji'ilM9M< The UPnP model of Controlled Devices, The Device 
Model includes the addressing schemes, Description Document, Devices 
25 and Services hierarchy and the functional description of Services, 
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and schemes used to Interact with a UFnP Controlled Device, 

Device Definition, The formal definition of a Device Type, A Device 
Definition includes a Device Type identifier, the fixed elements in the 
5 Description Document, the required set of Service Definitions in the Boot 
Device, and the hierarchy of required Devices and Service Definitions. 

Service Dgfinstlon. The formal definition of a Service Type. A 
Service Definition includes a Service Type Identifier, definition of the 
Service State Table fSSTL definition of the Service Command Set, the 
10 Service Control Protocol {SCP) and Service Control Protocol Declaration 
(SCPDh 

Bgvi&fc In the context of the Device Model,- a container for Services. 
A Device generally models a physical entity such as a VCR, but can also 
represent a logical entity. A PC emulating the traditional functions of a 
1 5 VCR would be m example of a logical device. Devices can contain other 
Devices. An example would be a TV/VCR packaged Into a single physical 
unit, UPnP enables the association of user interface (display icon and root 
Web pagei with every Device, including Root Device, 

Root Device. The topmost Device in a hierarchy of nested Devices, 
20 A Device with no nested Devices is always a Root Device. 

.feeyic e Type - A relatively high level classification of Devices with 
common functionality. Device Type Is intended to enahfe Devices to be 
simply and automatically grouped for search and/or presentation, An 
example of a Device Type is "VCR", Device Types are formally defined In 
25 terms of a required set of Service Definitions of minimum version that a 
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compliant Device must support. UPnP supports searches for all Devices of 
a specified Device Type, 

Ooysce Ty; idrm A unique or mat jdentifjes a Device 

Definition, This identifier adheres to the format of a Uniform Resource 
5 identifier (UBIK See, I, 8emers4.ee, R, Fielding., L. Maslntef, Uniform 
Resource Identifiere CURi): Generic Syntax, IETF RFC 2398 (August 1998), 

Devio --, ■ • 3 tie. A human readable string that is usually 
initialteed by vendor® at the time of manufacturer of a Device. Every 
Device, including Root Devices, has a Device Friendly Name. A typical 

10 Device Friendly Name will contain manufacturer and modal information., and 
especially when interpreted by humane, can be used to enable a Mora 
precise identification of a UPnP Device from the sat of discovered Devices, 
Once identified, the Unique Device Name (UDNi can be used to 
unambiguously identify the same Device in the future. UPnP enables 

15 Device Friendly Names to be changed by User Control Points, The Device 
Friendly Name should not he used es device Identifier, 

Unique Device Hame fUDNh The fundamental identifier of a Device, 
Every Device, including Root Devices., has exactly one UDN. The UDN is 
globally unique arid permanent, even across power cycles and physical 
20 location changes. The UDN is the only UPnP device identif ier guaranteed 
never to change. UPnP enables searches for devices by UDN, 

<n i m<< m x n - red unit of data that ;s used by a 
User Control Point or UPnP Bridge to learn the capabilities of a Controlled 
Device, Description Documents ore rHnoved from rhe Description Server 
.28 on a UPnP Contr oiled Device. There is one Description Document fos every 
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Root Device that describes the Root Device and ail non-Root Devices, 
Description Documents adhere to XML grammar. To support localization, 
multiple Description Documents can exist, A User Control Point, requests 
the preferred localized Description Document by using the standard HTTP 
5 i 'accept-lsf■^guage' , header, 

S^MS- The fundamental UPnP controllable entity (but not the 
finest level of control*. An example of a Service is "Clock". Services are 
defined with a mandatory common base set of functionality, Vendors can 
extend the base set with proprietary extensions provided the base 

10 functionality is implemented. Service Definitions are versioned and later 
versions are constrained to be supersets of previous versions, VPnP 
enables searches for ail Devices that contain a specified Service of a 
minimum version. This searoh woylcl find all clocks, regardless of their 
packaging, A search for Device Type "Clock" would fee used to find only 

1 8 stand-alone clocks, 

SeryMlyje, A classification of Services by their function. 

Service Type Idemm^r. A unique identifier that Identifies a Service 
Definition, This identifier adheres to the format of a Uniform Resource 
identifier CURD. See, T. Berners-Lae, R, Fielding, L Masinter, Uniform 
20 Beso»me ttttati^-fUBlfc Generic Syntax, IETF RFC 2398 {August 1 998). 

Sgrvice Stata TaNt iSSIi, A logical table consisting of rows of i 
Variable, Type, Legal Vatuas, Default Value, Current Value J that represents 
the current electrical, mechanical and/or logical state of a Service. SST 
instances are stored on the Controlled Device itself and are the ultimate 
25 authority of the state of the Service, All local user Interface, such as front 
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panels or wireless remotes are required to update the SSI on UPnP 
c o m p I ? a nt d e vi ess . 

Service Command Set. A set of Commands that can be invoked on 
5 a Service. Commends generally result in changes in the Current Value field 
of one or more rows of a SST. Commands are logically represented in the 
format Command ( Variable ** New Value, Variable « Afew Vaft/e, ... ). 
Services must accept or reject the complete eat of changes to a SST, 
There is a mandatory standard Query Command that is used to retrieve the 
10 Current Value of any mw of a SST. 

Sfrryfo* Control P^orqI ^SCP^ The protocol used to invoke 
Commands against a Service and to return results. There is exactly one 
SOP per Service Definition. SCPs adhere to the grammar of SCP XML 
1 5 schema, SCPs can he generated by an automated tool that accepts a SST 
Definition and a Command Set Definition as Input. 

ggSfet ..Control P; P^^i>§glggg|jO0..iggPDK A formal 
representation of the schema of a Service. The SCPD declares the rows of 
a Service's SST and the associated Command Set, SCPPs are uploaded 

20 from Controlling Devices in their Description Documents and enable User 
Control Points or Bridges to invoke Commands on the Service without any 
prior or persistent knowledge of the capabilities (or schema) of the Service. 
There is exactly one SCPD per Service Definition. SCPDs adhere to XML 
grammar, SCPDs can fee generated by an automated tool that accepts a 

2S SST Definition and a Command Set Definition as Input, 
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Event. An unsolicited message generated by a Controlled Device 
and delivered to one or mom User Control Points, Events are used to 
maintain a consistent view of the state of Service across ail interested User 
Control Points. UPnP leverages the GENA event architecture (see "Generic 
5 Event Notification") to transport event messages. All events are delivered 
using TCP/IP for reliability. 

Genen^ An event transport 

protocol. GEM A leverages TCP/HTTP as a transport. GENA has been 
submitted as an Internet Draff to the IETF. See, J. Cohen, S. Aggarwal, T, 
1 0 Gofand, fignamtEwwt H^m^.mmmiiteBimt aiem to Arbiter . 
IETF Internet Draft., "draft-coh8n-gena-dlent-00.txt. " 

WMpM^mMmmt&mMmmn^ A simple network device 
discovery protocol UPnP uses SSDP to allow User Control Points to find 
Controlled Devices end Services. SSDP operates in a default, completely 

IB automatic multicast UDP/IP based mode in addition to .a server-based mode 
that uses TCP/IP for registrations and query. Transitions between the 
default dynamic mode and server-based mode are automatic and 
transparent to upper level software. SSDP enables every Controlled Device 
to control the lifetime that its Description DHL is cached in all User Control 

20 Points, This enables a Controlled Device to remain visible to User Control 
Points for a relatively long time {through power cycles), in addition to 
enabling a Controlled Device to appear and disappear very quickly, all imder 
the control of the Controlled Device. SSDP and related Multicast end 
Unicast UDP HTTP Messages specifications have been submitted as 

25 internet Drafts to the IETF, See. V. Goland, lyiujticasj and Unicast UDP 

11 1 11 usages I! f? In e net Draft di H g la id I ttp-udp-00.txt;" and Y. 
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Goland, T. Cai ; P Leach., Y. <3u, S, Albright. Srnoje Seryic, Discovery 
Protocol/1 .0, IETF Internet Draft, "draft-cas-ssdp v ! 02 txt." 

CHent. In the context of UPnP, Client refers to a module that 
initiates a TCP/HTTP connection to a peer HTTP server, 

5 §^ver. in the context of UPnP, Server refers to an HTTP server. 

This is a module that accepts incoming T CP/HTTP connections and either 
returns a Web page or forwards the payJoad data to another module. 
Client and Server describe only th« direction of initiation of TCP/HTTP 
connections. There is no relationship between the 'low level concepts of 
1 0 Cfmnt and Server and the high level concepts of User Control Point and 
Controlled Devices. Logically, User Control Points always discover and 
initiate communication with Controlled Devices,- hut this communication 
requires Client and Server functionality on both sides, 

Jd^OSES- A Hostname is the Domain Name System {DNS} or 
1 5 NetBIOS Memo Service (fMBMS) that, when resolved to an IP address, 

represents a network Interface that can be used to establish TCP/IP level 
connectivity to User Control Points, Controlled Devices or Bridges. 
Hostnames can be used to provide persistent network level addressing on a 
network where IP addresses are dynamically assigned and of unknown 
20 lifespan or to integrate with an existing managed network. UPnP provides 
an algorithm for seeding a device's hostname from its UDN at 
lan da j timt 

v t> : ^sou*^ . oi , A format for expressing Weh 

addresses. URLs minimally contain an identification of the protocol family 
25 that the URL is valid for, a Hostname, and a path. UPnP uses URLs as 



22 



addresses whenever the module accepting the incoming connection is an 
HTTP server. 

Pescr^tlon URL, The URL returned from a Controlled Device or 
Bridge m response to any UPnP SSDP query. This URL always points to a 
5 Description Server on the Controlled Device. An HTTP GET can be issued 
on this URL to retrieve the Description Document, This URL is valid as an 
address for the lifetime of the Hostname embedded in the URL 

Discovery Server. The module that runs in a Controlled Devioe or 
Bridge that responds to SSDP queries. This Server Is unique m that It must 
1 0 support U DP/HTTP in addition to TCP/HTTP. 

Discovery Client, The module that runs in a User Control Point that 
initiates SSDP queries. 

Description Server . The module that runs In a Controlled Device or 
Bridge that responds to HTTP GETs and returns Description Documents. 
1 B This service consists of a TCP/HTTP server than can retrieve and return a 
Description Document from persistent storage {like a fttesystsm), 

M^t^teiSO. User Control Point functionality that displays the 
icons of discovered Devices and enables the transfer of control to a 
browser or application to interact with the Controlled Device, in Windows, 
20 Visual Navigation could be implemented as a folder of icons. 

Presentation URL A URL that can be used by a User Control Point 
to navigate to the Presentation Server of a Controiled Device . This URL is 
returned in the Description Document and is valid as an address for the 
lifetime of the Hostname embedded in the URL AW Devices, including non- 
25 Root Devices,, can have an associated Presentation URL. 
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Presentationjervgr. A Web Server in most common cases. The 
module that runs in a Controlled Device that responds to HTTP QgJs or 
Presentation URLs and returns user interface using Web technologies 
(JavaScript, Jseript®, SCMAScript, VBScript, ActiveX®, Java Applet, etch 

5 Browser. A Presentation Client. A Web browser extended with a 

Behydrator. 

Control URL. A URL that can be used by a User Control Point to 
navigate to the Control Server of a Controlled Device or Bridge. This URL 
is returned in the Description Document and is valid as an address for the 
10 lifetime of the Hostname embedded In the URL, AH Services have an 
associated Control URL, 

Controi Server . The module that runs in a Controlled Device or 
Bridge that responds to Commands invoked on a Service by 3 User Control 
Point. Commands ere encoded and sent using the SCP specified in the 
1 5 Service Definition, This service consists of a TCP/HTTP server that passes 
control to the native control logic of a Service., updates the SST and 
generates an event if the SST changes. 

Behydrator. In UPnP, a Controi Client, A User Control Point module 
that translates between native operating system APIs and SCPs and 
20 events. The Behydrator uploads SCPDs from Controlled Devices and 
Bridges and generates appropriate SCPs in response to application API 
requests to invoke Commands, 

I^.Ll.^eH!PjJon._ym ; . A URL that can be used by a User Control 
Point to navigate to the Event Subscription Server of a Controlled Device or 
25 Bridge. This URL is returned in the Description Document and is valid as an 
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address for the lifetime of the Hostname embedded in the URL All 
Services have an associated Event Subscription URL. 

SufeacrtPtian Server. The module that runs in a Controlled 
Device or Bridge that responds to 6ENA SUBSCRIBE requests from User 
5 Control Points. A SUBSCRIBE informs the Controlled Device or Bridge of 
the User Control Point's desire to receive future events. This service 
consists of a TCP/HTTP server that adds the User Control Point's Event 
Sink URL to the list of destinations to be NOTIFY'" d whenever the SST 
associated with the Service change*. 

1 0 Event Subscription gjfejfc The module that runs in a User Control 

Point that sends QBHA SUBSCIBE messages to the Event Subscription 
Server. 

fyent Sink UBl, A URL, supplied by a User Control Point, that is 
used as an address to send event MOTIFYs to. This URL is valid as m 
I S address for the lifetime of the Hostname embedded in the URL There Is no 
explicit relationship between Event Sink URLs and Subscription identifiers. 

Subscrtp tfon IdeftilfSey l$\Dh A header in the GEM A NOTIFY 
message that identifies the source of an event, in UPnP, the SID can be 
considered as an alias for the Event Source instance. 

20 Event Sink. The module that runs in a User Control Point that 

accepts incoming GENA event MOT! FYs. This service consists of a 
TCP/HTTP server that passes the event information to Interested 
applications running on the User Control Point. 
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Event Source. The module that runs m a Controlled Device or Bridge 
that sends GEMA NOTIFY s to the Event Sink Servers of SUBSCRIBES User 
Gonvroi Joints, 

Oon.sii , — - n\» *0h ?X <>fstnomed system of servers that 
5 locates the IP addresses of other computers on a network based on their 
hierarchical names, 

NetBIOS Name Serve? (UBHSh A server that locates the IF 
addresses of other computers on a network based on their flat NetBIOS 

1 0 Multi cas t DMS C MPNS) . A peer-to-peer translation scheme that does 

hot require Involvement of D$S servers. 

yi!!£JM?.OMgglg- s . Overview 

An overview or technologies utilized in UFnF follows, 

1 5 TCP/IP provides the ability to Initiate a connection with a specified 

application running on a specific device, provided both the network address 
of the device {IP address) and the application address (port) are known, 
Gerteraliy, application addresses {ports) are standardized and widely 
known, but Tne propiem of sesminc} toe IF address of a device remains. 

20 Simple Service Discovery Protocol (SSDPl is a protocol that enables 

devices to learn of the existence of potential peer devices and the required 
information {an IP address! needed to establish TCP/IP connections to 
them. The successful result of an SSDP search is a Uniform Resource 
Locator (URL). The Hostname embedded In the URL can be resolved to an 
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\P address that can be used to make a connection to the discovered device. 

The name to address resolution Is outside of the functionality of SSDP. 

SSDP specifies a default completely automatic, best-effort multicast 

UDP-based operating mode, in addition to a server mode that uses TCP for 
5 registration and query. Fall-forward to server mode and fallback to the 

default dynamic mode can occur automatically and transparently as a 

server is added or removed from a network. Server mode can be used to 

reduce network traffic, to implement searches based on location or policy 

and to integrate with a directory system. 
1 0 SSDP requires that all devices specify a maximum lifetime that SSDP 

leva; knowledge of the device will remain cached in other network devices. 

If a device does not refresh the cache of other network devices before this 

interval expires, the device will be assumed to have disappeared from the 

network. This interval can be ohcssn to be larger than a typical power 
1 S down cycle to enable device visibility to persist for a relatively long time, or 

a smaller interval can fee chosen to enable more dynamic visibility control. 

in all cases, devices that are abruptly removed from the network will 

eventually disappear from ail networked devices. 

In response to an SSDP search, UPnP devices return a Description 
20 URL in the SSDP Location and optionally the Alternate Location (At) SSDP 

headers. An example location header is a follows: 

Location: http://deviceJocai/descnption/path/dascription,xml 

in this example, the device Jocal Is the Hostname of the Controlled 

Device, and the "description/path/descnption.xmi" element of the URL is 
28 the path and name of the Description Document on the device. 
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Eventing, in the context of UPnP, is the ability for a device to initiate 
a connection at any time to one or more devices that have expressed a 
desire to receive events from the source device, Events are used to enable 
5 synchronization among multiple devices organized into a many to one 
relationship. UPnP events am mainly used for asynchronous notifications 
of state changes, 

TCP/IP provides the fundamental support for the connections that 
carry event Information reliably. Generic Event Notification (GEM A! adds 
1 0 conventions for establishing relationships between Interested devices and 
an addressing schema to enable th« unambiguous delivery of events, 
GENA leverages HTTP addressing end encapsulation. 

y^LOS!^ Bndgeejnd OS Service 

Re noter/Piil ej 

1 S With reference now to Figures 1 and 2, UPnP is an application -level 

distributed network architecture where the logical nodes on the network 
are User Control Points 104- 105, Controlled Devices 108-107, Bridges 
1 20, and OS Service Remoter/Publisher 1 50, These classifications refer to 
functionality rather than physical entities. The functionality of UPnP User 

20 Control Points 104-105, Controlled Devices 105-107 and Bridges 120 can 
be packaged into physical entities (e.g., multiple function devices 102-1031 
in any combination. 

The primary distinction between a User Control Point 104-105 and a 
Controlled Device 106-107 is that the User Control Point is always the 

25 communication initiator. After the initial communication, User Control 
Points can receive events \ Q< vices 
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Controlled Devices 106.107 are responsible for storing and updating 
the state of Services. User Control Points are required to synchronize to 
the state on Controlled Devices and to share state directly among 

5 User Control Points typically have user Interface that is used to 

access one or mora Controlled Devices on the network. Controlled Devices 
typically only have local user interfaces. 

Bridges 1 20 (Figure 2} expose devices that do not expose native 
UPnP protocols as native UPnP Controlled Devices, The Bridge itself looks 

1 0 to other CP nP User Control Points like a set of Controlled Devices, 

Service Remoter/Publisher ISO (Figure 2) exposes services 156-15? 
of a general purpose operating system 152 (e.g., services provided in the 
Microsoft Windows operating system}* hereafter referred to as OS services. 
The Service Remoter/Publisher 150 emulates a set of Controlled Devices 

1 5 providing the operational functionality of the OS services, and thus appears 
as a set of such Controlled Devices to the UPnP User Control Points 104- 
105. The Service Remoter/Publisher 150 then interacts with the OS 
services through the conventional OS API exposed fey the OS services in 
response to the UPnP User Control Points 104-105 to effect remote control 

20 of the OS services from the UPnP User Control Points via the UPnP 
protocol. 

With reference to Figure 3, the Service Remoter/Publisher 1 50 
{Figure 2) is implemented in an exemplary general purpose operating 
26 system 1 52, which may be for example the Microsoft Windows operating 
system, as a UPnP Publishing Service 180 and a Service Remoter 182, 
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The general purpose operating system 152 provides a variety of 055 
services 168 that perform specific system functions to support other 
programs, Including application programs run on the operating system,. The 
illustrated OS services 166 Include date and time clock,, file and printer 
6 sharing,, print spooling, electronic mail, fax, telephony, file synchronization 
(e.g.,,. with mobile devices}, file backup and archiving, audio and video file 
streaming fe.g,, from local or remote storage., and to a peripheral play-back 
device, such as speakers or a monitor},, audio and video codecs,, file 
compression/decompression, problem diagnosis and support,, event !og#n& 

10 user and software configuration administration, security and access 
control remote access IRAS), networking (internet socket,. FTP, HTTP, 
TCP/IP, NetBIOS, etc,}, name and address (DHCP, DNS), remote procedure 
call (RPC) and named pipe, dynamic peripheral configuration (Plug and 
Play), and application scheduling (e x g., Windows BB system agent}., among 

1 5 others. In addition, the OS services can include extended services that 
plug into an extendible services architecture of the operating system, such 
as using the Microsoft Windows NT Services programming model (see, for 
example, J, Pichter, De sign A W indows NT Service To Exploit Special 
Operating System Facilities. Microsoft Systems Journal (October 19S?h 

20 The OS services 1 56 are exposed to programmatic control by applications 
and other programs running on the operating system through a sat of OS 
APIs 166 i&m thn . Microsoft Win32 API, which is described in Microsoft 
^mMmmm!mMMmMm> Microsoft Press (1 993}.} 

The UPnP Publishing Service 1 60 in the illustrated general purpose 

25 operating system 1 §2 is a program structured as a service of that operating 
system (e.g., as a Windows NT Service), and provides a publishing API 
1 64, The UPnP Publishing Service 1 80 operates as a general mechanism 
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for publishing the information necessary to emulate the functionality of 
devices and services running undm the general purpose operating system 
as Controlled Devices per the UPnP protocol for devices and services that 
do not themselves support the UPnP protocol. The Service Remoter 162, 
5 the Bridge 120, as well as Applications 1 70-1 71 use the publishing API 
1 84 to establish a Controlled Device emulation of their functionality by the 
UPnP Publishing Service 160, and provide the communications (such es of 
the service state and Commands from User Control Points) between the 
programs and the UPnP Publishing Service to effect the emulation as 

10 Controlled Devices, The UPnP Publishing Service 160 operates to publish 
Information such as discovery responses, service description, end service 
state, as well as direct responses to UPnP requests, to User Control Points 
104 for the sat of Controlled Daviess that it emulates. The UPnP 
Publishing Service 1 SO also passes information back to the devices and 

I S services running under the general purpose operating system (e.g.,. via a 
callback registered with the UPnP Publishing Service through the publishing 
API) to effect the Commands from the User Control Point 104 to the 
emulated Controlled Devices. Thus, for purposes of the User Control 
Poiom snnv.i* nog with the emulated Controlled Devices sn accordance with 

20 the UPnP protocol, the UPnP Publishing Service appears as the set of 
emulated Controlled Devices. 

The UPnP Publishing Service and publishing API allows the Service 
Remoter 162, the Bridge 120 end applications 170-1 71 to expose their 
functionality for remote control though the UPnP protocol without having 

25 to ind I $ip<ement ail the various components (described below and 
Illustrated in Figure 6) of a Controlled Device per the UPnP protocol. 
Instead, the UPnP Publishing Service implements the components of a 
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Controlled Device collectively for the set of emulated Controlled Devices. 
The Service Remoter 182, the Bridge 120 and applications 170-171 need 
only be programmed to use the publishing API, 

The Service Remoter 162 is a program module that operates to 
5 convert between the specific OS API of the particular OS services, end the 
publishing API of the UPnP Publishing Service 1 60. The Service Remoter 
182 uses the publishing API to effect emulation of the particular OS 
Services as UPnP Controlled Devices by the UPnP Publishing Service 1 60, 
which exposes the OS services' operational functionality to remote control 

10 by User Control Points via the UPnf protocol. Also, as information is 

passed back from the UPnP Publishing Service 1 60, such as for Commands 
from the User Control Points in the UPnP protocol Intended to control the 
OS services' operation, the Service Remoter 182 uses the regular OS API 
of the OS services to effect control of the OS services. This avoids having 

18 to restructure or reprogram the OS services as UPnP Controlled Devices, or 
even to themselves use the publishing API of the UPrvP Publishing Service 
180, 

Figure 4 illustrates an exemplary implementation of the UPnP 
Publisher/Remoter 100 (Figure 2) In the Miciosoft Windows operating 

20 system, In this exemplary implementation, the UPnP Publishing Service 
180 includes an instance of the Service Remoter 162 per each OS service 
1 88 that is to be exposed as a UPnP Controlled Device, and a single SSDP 
Service 1 88 shared by all remoted operating system services 1 56 on the 
system. The Service Remoter 182 In this exemplary implementation fully 

25 implements a UPnP controlled device that remotely exposes the 

functionality of the respective OS service 188. The Service Remoter 162 
includes a set of library modules 1 90-1 98 that implement the various 
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discovery, description, everstbg and control protocols of UPnP, as well as 
mapping code for converting communications with UPnP user control 
points per the UPnP protocol Into interactions via the OS API with the OS 
service 158. These protocol modules includes a UPnP Publishing API 
5 library 1 90, a SSDP server library 1 91 , an HTTP server library 1 92, a 

Sockets library 1 93, a GEN A server library 1 04, a SOAP server library 1 95, 
a GEM A publisher library 108, an HTTP client library 198, and an XML 

" D ; , ' 1 

The SSDP service 180 provides support for the SSDP discovery 

10 protocol for each OS service remoted through the UPnP Publishing Service 
1 SO, The SSDP service 1 88 includes a separate instance of the Sockets 
library module 180 end a publish list 188, Each OS service IBS to be 
remoted through the UPnP Publishing Service 180 is added to the publish 
list 1 88 of the SSDP service 186 via a call to the UPnP Publishing API 

15 library 1 90 and SSDP server library 181. The SSDP Service 1 86 then 
provides appropriate responses to SSDP discovery requests per the UPnP 
protocol for the remoted OS service 156. 

The Service Remoter 182 handles incoming UPnP description, 
requests and responses for the remoted OS service 158 via the Sockets 

20 library 1 93,. the HTTP server library 1 92, and the UPnP Publishing API 
library 1 90 modules. 

The Service Remoter 182 handles incoming event subscribe requests 
for the remoted OS service 156 vie the Sockets library 1 83, the HTTP 
server library 1 92, and the UPnP Publishing API library 1 90 modules. Oats 

25 for out-going event publishing for the remoted OS service 1 56 te.g„, the 
service's state) is handled in the Service Remoter 162 through the UPnP 
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Publishing API library 190, the GENA publish library 196, the HTTP client 
library 198 and the Sockets library 133 modules, 

The Service Remoter 182 further handles control commands of UPnP 
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User Control Points to the remeted OS service 1 66 via the Sockets library 
193.. the HTTP library 192, the SOAP server library 195, end the UPnP 
Publishing API library 190 modules. 

With reference now to Figure 5, the following table lists the modules 
In the User Control Points 104-105 and Controlled Devices 108-107, along 
with their functions. 




C ■ V > > 0 t >iy 






initiate discovery Discovery Client 

of Controlled 

Devices, 


Respond to Discovery 
discovery Server 


Retrieve Descnnn > > C lSe - 

Description 

Documents, 


Provide Description 

■ ■ :ription Server 
Documents . 


Display a folder Visual Naviga; on 

of icons per 

discovered 

Device and allow 

transfer of 

control to a 

selected device. 
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Vu w use; Web Browser 
Interface exposed 
by a Controlled 
Device, 


ae user Presentation 
inteface for {Web} Server 


Control Points, 


Execute Application 
applications. Execution 

Environment 




invoke Rehydrator 
Commands on a 
Controlled Device 
by sanding 
Service Control 
Protocols In 
response to local 
API calls- 


\< ^ept f r\ q d nro* Sep, r 
Commands in plus native 
SCPs and control logic 


Inform a Event 
Controlled Device Subscription 
of a desire to Client 
recesve Events. 


AcccpL fequ «,t« ' enl 

for Events and Subscription 

remember them. Server 


Receive an Event. Evcru Sink 


Send r , \ I . , t Sc. , - 



The UPnP Device Mode! 200 shown in figure S Is the mode! of a 
UPoP Controlled Device or Bridge that is emulating native Controlled 
5 Devices. The Device Model includes the addressing schema,, eventing 
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schema, Description Document scheme. Devices and Services schema and 
hierarchy, and the functions! description of modules. The UPnP Device 
Model extends beyond simple API or a command and control protocol 
definitions to enable multiple User Control Points to have a consistent view 
5 of Controlled Devices, This requires that the state of running services foe 
formally modeled end that all state changes be visible to User Control 
Points, Centra! to the distributed UPnP architecture is the rule that 
Controlled Devices are the ultimate authority for the state of Services 
running on them. 

10 UErfJervlce 

The fundamental controllable entity m \3?n? is a UPnP Service 210- 
217, Every running Instance of e UPnP Service includes: 
* A. Service State Table CSSTI 230, which represents the current state of 
tne UPnP tserxnee. 

W The SST 23G can be used to represent the operational mode of 

device or to act as an information source or sink for structured data or 
simple files. The SST of a VCR 264 {figure 8} could represent the 
current it i output 

switch selections, audio and video decoding format and current timer 

20 program. The SST of clock 2S1 (Figure 8} would likely represent the 

current time. The SST of an image rendering device could implement a 
video frame-buffer that can accept raw pixel information or formatted 
JPG files. The SST of an audio or video playback, device could 
implement a transfer buffer or queue of rnateria! to he played, The SST 

28 of PDA could implement a collection of formatted data that has changed 
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and needed to foe synchronized with another device, m addition to a 
transfer buffer for accepting incoming formatted data. 

The logical structure of a SST published in the Service Definition,, 
but the actual storage format of an instance of a SST is entirely up the 
5 device. The only interaction wrth a SST is through a formal application 
level network protocol. 

* A Control Server 235, which accepts incoming Commands expressed in 
the UPnP Service's Service Control Protocol (SCPh The Control Server 
passes the command to the UPnP Service's native command processing 

1 0 logic and waits for command completion. When the command is 

completed successfully, the SST is updated, an event is generated,, and 
a successful response is returned to the User Control Point, In the 
event of an illegal command or unsuccessful command, no changes are 
made to the SST and a failure response Is returned. The Command and 

W response sequence Is payioad to a TCP/HTTP request/response. 

* An Event Subscription Server and Event Source 234. The Event 
Subscription Server accepts Incoming GEN A SUBSCRIBE messages from 
User Control Points and adds them to a list of User Control Points 
interested in SST change events from the UPnP Service, The Event 

20 Source initiates a TCP/HTTP connection to each interested User Control 
Point and sends a GENA NOTIFY each time the UPnP Service's DST 
changes. The NOTIFY payioad includes the changed contents of the 
DST. 

* A Centre! URL that identifies the Control Server. 

26 * An Event URL that identifies the Event Subscription Server.. 

The formal definition of a UPnP Service {Service Definition) includes: 
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* The definition of the SSI, SST layouts are log < iih specked in terms 
of rows of 1 Variable, Type, Legat Values, Default Value I The actual 
Instance of a SST would also include a Current Value field in every row.. 

• The definition of the Service Command Set that can he Invoked against 
5 the UPnP Service's SST. Commands are logically specified in terms of 

Command i Variable « Mew Value, Variable a tfefee, .... ). If a 
Command results in more than a single Variable change, the updates are 
atomic and the Command will fall if if Is illegal to make the specified 
change to any one Variable. 

10 * The definition of a structured unit of data called a Service Control 
Protocol Declaration {SCPD). SCPD Is used to advertise the layout 
Schema) of the SST and Command Sat of the UPnP Service to a User 
Control Point or Bridge, The SCPD enables the User Control Point to 
invoke Commands (through the Rahydfator) on the Controlled Device 

I S without any prior or persistant knowledge of the capabilities of the 

device. The SCPD Is uploaded from the Controlling Device as part of 
the Description Document, Generation of the SCPD for a UPrtf* Service 
based on Its SST definition and Command Set definition can be fully 

20 * The definition of a network protocol used to invoke Commands against 
the SST associated with a UPnP Service and to return results. The SCR 
can he generated from the SCPD, The Rehydrator's job is to convert 
SCPDs into SCPs. The reason for a formal SCP specification is to 
enable the implementation of the Control Server itself and to enable 

26 simple peer-to-peer devise interopsration using only published protocols. 
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* An identifier, called the Servic* Type identifier., that identifies a unique 
Service Definition. Service Definitions ere wrsioned in controlled 
manner. Every later version of a UPnP Service must be proper superset 
of too previous version. 

According to the device model 200 shown in Figure 5., a UPnP 
Device 202-205 (e.g., multiple function devices 102-103 of Figure 1 and 
bridged devices 122-123 of Figure 2) is a logical container of one or mom 
UPnP Services 210-217. Generally a Device represents a physical entity 

10 such as a VCR. Typical UPnP Services in the VCR Device example might be 
TRANSPORT", TUNgfT, TIMER" and "CLOCK*. While Devices are 
often physical entities, a PC emulating the traditional functions of a VCR 
could also be modeled in the same way as the stand-alone VCR. Devices 
can contain other Devices. An example would be a TV /VCR 250 {Figure 8} 

IS packaged into a single physical unit. A Device (e.g., devices 202-203) 

may also be a logical container of other Devices, The top-most Device m a 
hierarchy of nested Devices 203-205 is called the Root Device 202. A 
Device with no nested Devices is always a Root Device. 

The UPnP Device Model was designed to be general and flexible, it 

20 should be possible to model an entire Nuclear Power Riant as a single UPnP 
Service or as a deeply nested hierarchy of Devices and UPnP Services. In 
general, a UPnP Service 210-217 is cohesive set of functions that enables 
flexible packaging Into a variety of Devices. UPnP Services can be 
verstoned independently of Devices. 

25 Alt Devices, including Root Devices belong to one or more Device 

Types. Device Types are intended to enable instances of Devices to be 
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simply and automatically grouped for presentation, An example of a 
Device Type Is "VCR"' 2S4 (Figure 8L Device Types are formally defined in 
terms of a minimal set of versioned UPnP Services that a Device of Device 
Type must support. Device Types are not formally versioned. Device Type 
5 is a relatively high level grouping. A Device of D&vice Type only ensures 
that minimal set of UPnP Services of a minimal version is present, There 
can be other UPnP Services, higher versioned UPnP Services and UPnP 
Services with vendor extensions present on such a Device, 

UPnP enables SSDP level searches for a unique instance of a Device 
1 D {by UDN}, all Devices of type B&wca Typs and all Devices that contain at 
least one Service Type of minimum version. The result of an SSDP search 
is always a UHl that points to the Description Document contained in the 
Hoot Device. In the event that matching Device is not the Boot Device, the 
Description Document has a tree of nested Devices that can be traversed 
1 5 to find the matching Device, 

Every Device includes: 

* One or more Device Types, 

* One or more UPnP Services. 

* Optionally, one or more Devices. 

20 ♦ Optionally, a Presentation (Web) Server 220-223 that can be used to 
expose Device user interface. Every Presentation Server has an 
associated Presentation URL 

* A globally unique identifier called the Unique Device Name (UDN), The 
UDN is the fundamental identifier of an instance of a Device, Every 

25 Device, Including Root Devices, has exactly one UDN. 
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Every Root Device 202 also includes the Description Document 226 
and Description Server 228 for elf Devices under and including itself. 

The forma! definition of a Device {Device Definition 226} includes: 

* The fixed elements of the Description Document that describe the 
S Device. 

* The required hierarchy of Devices and Service Definitions, 

There can he many Device Definitions that belong to a single Device 

Type. 

QSYiSe Tyjoes 

1 0 The forma! definition of a Device Type includes: 

* A Device Type Identifier, 

* The required hierarchy of Devices and Service Definitions of minimum 
versions. 

,S^# ; Stata Table 
1 5 A Service State Table SSST) logically consists of rows of: 

Variable, Type,. Legal Values, Default Valu®, Current Value 
Although entries of the Service State Table in UPnP consist of these five 
Herns, the state table alternatively can contain fewer or additional items. 
Generally, each entry will minimally consist of a Variable name or identifier, 
20 end its current value. 
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The following table lists various Types available in UPnP, 



Type 

String 



Description 

A sequence o UN CODE ■ t -re. 
A numbs \ digits; may 



15, 3 J 4, - 
123.456E+10 



fractional digits, and 
exponent. Punctuation 
English 



as in US 



TRUE or FALSE. 



DateTime 



A date in 1308801 format, with 



19941 106108:1 
5:5 + 03 



Fractional seconds may be as precise 
as nanoseconds. See, Data Elements 
And InterchangeFpfmats - Information 
iMfrctoga - Representation Of Dates 
And Times, international Standard, ISO 
8801, First Edition 1988-06-15. 



ByteBlock 



An 



The ByteBtock is essentially a data buffer. In one use, a variable of 
tMs type can be used to effect transfer of a file from the Controlled Device 
to th* User Control Point. The file to be transferred is kept in the Service 
Stats Table as the current value of this variable, On a change in the file, 
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the file is transferred to any subscribing User Control Point m en event 

The reason for representing UPnf Services this way is to ensure that 
the state of a UPnP Service is easily available in a common way to multiple 
5 User Control Points, 

An SSI can be used to represent to current operational mode of 
device, act as an information source or sink and/or simply be a repository 
for commands. The SST of a VCR UPnP Service could represent the 
current transport mode, tuner channel selection, Input and output switch 
1 0 selections,, audio and video decoding format and current timer program. 
Alternatively, the VCR 254 could be represented as a Transport UPnP 
Service 260, Tuner UPnP Service, I/O Switch UPnP Service, AN Decoding 
Configuration UPnP Service and Programmable Timer UPnP Service 281 . 
The SST of a clock 261 would likely represent the current time, 
1 8 Additionally an alarm clock could include Service Variables to configure the 

The SST of an image rendering device could implement a video 
frame-buffer that can accept raw pixel information or formatted J PCs files, 
The SST of an audio or video playback device could implement a transfer 
20 buffer or queue of material to be played. The SST cf PDA could implement 
a collection of formatted data that has changed and needed to be 
synchronized with another device, in addition to a transfer buffer for 
1 pti? g formatted data. 

User Control: mm Svnfejfronfeatkm 
25 In accordance with an device state end eventing mode! illustrated in 

Figure 7, UPnP rules require that every change to an SST generate a 
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corresponding event to announce the change to the a!? interested User 
Control Pomts. 

With reference now to Figure 8, UPnP is built on top of HTTP and 
8 leverages the native address format of the Web, Uniform Resource 
Locators {URLs}. URLs minimally contain an Identification of the 
application protocol family (»http»\ that the URL is valid for, a Hostname 
and a path, in the context of UPnP, the path part of a URL can represent 
either a filesystem path or simply an identifier of the local system meddle 

1 0 and context that can process Incoming messages. 

While UPnP modules are described as HTTP servers., there is no 
requirement that implementations be based on actual Web servers, in most 
cases, the job of the HTTP server Is simply to accept the incoming 
connection., look at the local destination part of the address {the path! and 

1 8 forward the payload to another module. UPnP enables, but does not 
require, that' all HTTP Servers be based on a common software 
implementation or runtime Instance. Controlled Devices and Bridges can 
include a TCP port specification as part of a URL to override the default 
vaiue of SO. 

20 The successful result of a SSDP level search in UPnP is always one 

or more Description URLs. These URLs cars be used to navigate to the 
Description Document of a Controlled Device or Bridge, A User Control 
Point uploads the Description Document and extracts the URLs of the 
Servers running on the Controlled Device or Bridge. 

25 AH URLs returned in the Description Document have a lifetime equal 

to the lifetime of the Hostname embedded In them. User Control Points 



44 



r. 5 i 



can store these URLs as addresses without going through a search 
sequence first. Once they have been advertised In a Description 
Document, Controlled Device end Bridges cannot arbitrarily change Server 
URLs. 

5 Whenever a Hostname changes, ail URLs associated with ail Devices 

addressed by that Hostname are invalidated. The UDN is the only UPnP 
identifier guaranteed never to change. Any persistent associations 
maintained by applications should at feast store the UDN to able to 
unambiguously identify the target Device, 

10 The lifetime of a Description URL is determined by Controlled Device 

or Bridge that advertises it. If a Controlled Device or Bridge allows an 
SSDP advertisement of a Description URL to expire, the URL Is invalidated. 
User Control Points use the Event Subscription URL returned by the 
Controlled Device or Bridge to connect to the Event Subscription Server, 

1 5 This server does the housekeeping of remembering ail User Control Points 
that are interested in receiving Events on a UPnP Service,, The Event 
Subscription Server needs an address to send the events back to. This 
address is called the Event Sink URL t and is supplied to the Controlled 
Device or Bridge In the <3£MA SUBSCRIBE message. The lifetime of an 

20 event subscription, and the Event Sink URL, is determined by the timeout 
en the SUBSCRIBE message. 

Further details of W addressing ere listed in the following table. 
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Description Pohks to the Oescr p < \ oath on . 

URL Root Device, This URL is returned by the Description 

Server as part of the discovery process. 



Presentation Points to a Presentation (W^ Server on a Controlled 
UBL Device. There is one Presentation URL per Device, 

including Root Devices. This URL can be entered into the 
address bar of a Web browser to navigate to the root 
Web page of a Device. This UBL is returned in the 
Description Document. 



Control UBL Points to th« C *tro! Serve, in 

on a Controlled Device, There is one Control URL per 
Instanc® of a UPhP Service. This URL Is r&iumvd m the 
Description Document. 



Event Points to an Even? ^ n v; « n «kjvu on a Controlled 

Subscription Device. This UBL is returned in the Description Document. 
URL 

EvenTsink UBL. Points to an Eve- t Sink (an h I i P Servers on a User 

Control Point. This URL is specified by the User Control 
Point in the GEN A SUBSCiBE message. 
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c , ^ > f m I ,n ihcafcon 
UPnP enable < SSOP s earc n s or a u * at. . Roet or non-Root Device 
by UDN, devices of a specified Device Typo and devices containing a UPnP 
Service of a specified Service Type. 

5 

UPnP SSDP Level Searches and ffesuffe 



A unique Boot A single Description URL pointing to the Description 
Device (by Server and Document path on the Root Device. 

wm 

A !i ' 1 ^ A single Ca » 

Root Device (by Server and Document path on the Root Device thai 
DON) contains the non-Boot Device. 

Type of Device A ^.u or Dsscnpnon URLs po nt -f| to the Description 

Servers/Document paths of at! Root Devices that match 
the Device Type, or contain a non- Root Device that 
matches the Device Type, 

o ^ - - U< ctipuon URLs po 1* g 1 j Desc iption 

Servers/Document paths of all Root Devices that contain 
a matching UPnP Service,, or contain a non-Root Device 
that contains a matching UPnP Service, 

SSDP specifies Service Type {ST},, Notification type {NT}, and Unique 
Service Name (USN| header fields for queries and for announcements. 
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UPnP uses the ST or NT header to carry one of the UPnP defined 
identifiers. A unique USN is required for each unique SSDP announcement. 

Multiple instances of the same Service Type within a Controlled 
Device 106-10? or Bridge 120 are not independently announced. 
5 UPnP search identifiers are used during the discovery process. The 

result of a successful discovery is one or more Description URLs. The 
format for search identifiers is: 



upnp: search type : [ ail format \ UDN format. \ 
10 srvf arms t j dev format ] 

mazahtyp® - £ vm \ SrvType } PevType j all 

15 all foxmat - all 

UDM format : " UDN : namespace t uniqu&id 
namespace « ; GUID j IEEKPPC j 1394] 

20 rv£oxma > e ic \ o 



UPnP Search Identifiers 



Unique Device 


upo.p:UDN ; na mespece-M 


upn . : 0 D N PPL M AC :0C009 


Name (UDN) 


nsqmid 


9123456 


Devsee Type 


u| ip Devi fpe:tf« cep 


upnp DevTyp ( \ r 








Sen o v: 


UP jL 5-r Tv- S-v, { tfy 


upnp SrvType cot< f 



SSDP specifies that SSDP announcements must be made for ail 
SSDP searchable values. The SSDP announcements with "air as the 
notification header value most carry the Root Device UDN as the USN 
8 header value. SSDP announcements for Device Types must carry the UDN 
of the Root Device concatenated with the Device Type URI as the USN 
header value.. SSDP announcements for a Service Type will carry the UDN 
of the Root Device concatenated with the Service Type URI value as the 
USN header value. SSDP announcements of UDNs will repeat the UDN 
1 0 value as the USN header. 



UPnP SSDP AtmQuncem&nts 
Xttnouncement ([Pi^io^ficatlon ~ SSDP USN 

Type . . 

"all* " Ptoot^evice UDN 

Unique Root Root Device UDN Root Demi' UDN ' 
Device 

Unique non-Root Non-Root Device Nmvioot Device UDN 
Device UDN 

Device Type Roo Device UDN Device Type 

Identifier Identifier 

Service Type Service Type Root Device UDN - Servku Type 

foemmer ioentnier 
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UPnP Bridges 120 {Figure 2) announce Bridged Devices 122-123 and 
associated UPnP Services using SSDP, The identifiers associated with the 
Bridged Devices are unique for the device, and they do not duplicate 
identifiers for Controlled Devices and UPnP Services directly available on 
5 the Bridge itself. This means that a Bridge that is also a Controlled Device 
most announce Bridged Devices and local Controlled Devices 
independently, with appropriate unique identifiers.. Description Documents 
and associated URLs. 

TO The UPnP Description Ooeufnant £28 {Figure 5) provides the 

information necessary to identify,, describe, connect and control a UPnP 
Controlled Device 106-10? or Bridge 120 from a User Control Point 104- 
10$. 

The Description Document is an XML document.. UPnP defines the 
1 5 use of HTTP end XML for the Description Document and wire protocols. 
UPnP adhwes to the schema declaration rules of XML-Data and Y. Goland, 
"Flexible XML Processing Profile." 

The top level XML elements are separated Into three categories: per 
Device, per UPnP Service and shared.. 

With reference now to Figure 9, all {UPnP} Controlled Devices 108- 
107 (Figure 1} or Bridges 120 {Figure 2) expose one or more UPnP Services 
210-21 7 (Figure 5} that can be controlled remotely. Controlling such UPnP 
Services involves a message exchange between a User Control Point 104 
25 and the device 106, This message exchange happens according to a 
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specific Service Control Protocol (SCP) 402, which specifics the content 
and sequence of the messages exchanged. 

User Control Points 1 04 are not required to have any prior 
knowledge of the SCPs 402 required to control the UPnP Services on the 
5 various devices. Therefore, a Controlled Device or Bridge must be able to 
describe to a User Control Point the protocols required to control its UPnP 
Services, such that the User Control Point will foe able to implement these 
protocols dynamically. This requires a standard way of declaring Service 
Control Protocols in a concise end unambiguous fashion. UPnP introduces 
10 a technique for declaring Service Control Protocols using a series of XML 
documents. 

A Rehydrator 410 is a module that exposes a suitable API to 
applications and either invokes Commends on a UPnP Service or queries 
the state of that UPnP Service, or receives and responds to events. The 

1 5 primary job of the Rehydrator Is to map between API ceils and the Service 
Control Protocol sequence that invokes the Command, 

As part of the Service Definition 406, a Service State Table 230 and 
Command Set 408 are defined. These things can be combined in a 
deterministic way defined by UPnP to produce a Service Control Protocol 

20 Definition (SCPD) 406, which includes e Service Control Declaration 404 
and a Service Control Protocol 402, The SCPD 408 is a representation of 
the schema of a UPnP Service, it is possible to reconstruct the SST, 
Command Set and SCP from the SCPD. 

The SCPD is directly &mbed4®<i into the Description Document 226 

26 of a Controlled Device. When the Description Document is uploaded into 
the User Control Point 104, the Rehydrator 41 0 can extract the SCPD from 
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it. At this point, the Rehydrator has enough information to issue UPnP 
Service specific SCPs 402, 

£ LQoifai i thejehydratet 
More generally with reference to Figure 10, the Rehydrator 410 
5 operates as a universal adapter to provide a programmatic interface to any 
service-specific protocol of a remote computing device. The Rehydrator 
410 simply obtains a data description or declaration of the methods,., 
properties and events of the remote UPnP Service, as well as a definition of 
the protocol of network data messages through which the Rehydrator 

10 invokes the methods, queries or sets the properties, and receives event 
notifications. In UPnP, this data description takes the form of the 
Description Document 226., which contains a Contract 41 2, The Contract 
defines network data packets 413 (e.g.... XfvIL data), request/response 
patterns, and protocol (e.g., GENA, HTTP, SSDP) via which the packets ere 

18 exchanged. This Information is sufficient for the Rehydrator to exchange 
the appropriate network data packets to interact with the Controlled Device 
Service, including to invoke commands, query and set properties., and 
receive and respond to events, without download of any executable code 
to the User Control Point 104 device and with a zero Installation or 

20 

The Description Document 226 also includes a declaration of the 
methods, properties and events for the UPnR Service. Based on this 
declaration, the Rehydrator produces a corresponding programmatic 
interface for use by applications at the User Control Point, The 
25 programmatic interface is an application programming interface that can be 
in the form of an object integration interface of an object-oriented 
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programming model such as Microsoft COM, CORBA, Java classes, and 
scripting engine name extensions, in the example illustrated In Figure 1 0, 
the Rehydrator 410 exposes a COM object integration interface riClock" 
interface 4141, with methods gsttimeO and setTimeO, for a Controlled 
5 Device having a "Clock" UPnP Service with GetTime and SetTlme 

commands. The Rehydrator 410 converts cs«s of an application program 
416 to the ICloek interface 414 into the network data messages specified 
in the Contract to invoke the corresponding commands of the Clock UPnP 
Service, The Behydrator 410 likewise creates suitable further 

10 programmatic interfaces for other UPnP Services te.g„ UPnP Services 21 0- 
21? of Figure 5} based on the Description Document of their respective 
Controlled Devices, 

Accordingly, the Behydrator operates as a universal proxy object 
with data-driven conversion of programmatic interfaces to network data 

1 5 messages. Further,, the Behydrator produces the programmatic interface at 
the User Control Point based solely on an XML data description. This 
operation allows the Rehydrator to produce just-tn-time transient interfaces 
to remote device UPnP Services without the complexity of code downloads 
and installation or configuration. Upon a later release of the interface by 

20 the application, the Behydrator destroys the interface without need to de- 
install or clean up persistent configuration data in a registry or configuration 
file of the operating system or object execution run-time, 

■Summary^ With reference to Figure 11, a preferred implementation 
26 440 of the Behydrator 410 is as an internal Microsoft Windows component 
that routes service control requests from the UPnP API to devices. 
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Applications wishing to control a UPnP Service on a UPnP device obtain a 
Service object through the UFnP APland use the methods of this object to 
query the state variables of the UPnP Service and invoke its actions. Those 
methods use the Rehydrator API to turn the UPnP Service control requests 
5 into network messages that travel to the UPnP device. In this sense, the 
Rehydrator performs a mapping between API calls and network protocols. 

Basic Functionality. The preferred implementation of the Rehydrator 
is able to translate a service control call to the UPnP API into the 
appropriate network messages defined by the Service Control Protocol. 
10 Asynchronous Eve n, U > ,^ « n. The preferred implementation of 

the Rehydrator is able to notify UPnP API clients of any asynchronous 
events generated by the devices they are controlling.. Event notification is 
done by means of the event interfaces defined below. 

Error R eporting. For a variety of reasons, state variable queries and 
IB action invocations may fail, The preferred Implementation of the 

Rehydrator Is able to provide a way to communicate the success or failure 
status of such operations to the parties initiating them. 

Rehydrat or Implementation De sign, As illustrated In Figure 11, the 
preferred implementation of the Rehydrator is used in two ways. First, the 
20 Device Finder 480 uses it to create Service objects 480, Then, these 

Service objects use it to carry out service control operations (querying state 
variables and invoking actions), 

CEteaflns Service Objects . When the Device Finder 450 creates a 
e\ e ob t t t N < *- 4 0 *o eraah : is 480 

25 for each of the service instances on that device. Each service instance 
supports a particular Service Control Protocol and the Rehydrator needs a 
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description of this protocol in order to create a properly hydrated Service 
object. 

The Service Control Protocol is declared in two separate XML 
documents: the DCPD and the Contract. The Rehydrator needs the 
S information in both documents. These two documents are passed to the 
Rehydrator as fXMLDOMDocam&nt interface pointers in the 
R&hydratorCrBateServheOhj&ctf} API calL 



created Service object. In addition to the creating the Service object, the 
Rehydrator sets up its internal data structures so that it can properly handle 
requests to control the UPnP Service. Specifically,, it creates a list of the 
properties and actions exported by the UPnP Service, Since all service 

20 instances of the same service type export, the same properties and the 
same actions, this Information is kept only once for each service type and 
is Indexed by Service Type identifier. 

The Rehydrator stores the information thai is specific to a particular 
service Instance as private data within the Service object itself. This 

2S includes the control URL and information about the control server 232 
(such as the HTTP verbs it supports}. The Service Type identifier Is the 
n i , oe > ^ * , f >nu >ne *^ unve 1 1 a se*\oee 

type and the Rehydrator internal date structures that contain Information 
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rGreateServiceObject ( 
DOHDocument *pDCPD, 

*pC< cact ')c zum nt,. 
XUPn&Se.rvice - \ >: u u<orv , »-«oh-* ec - * « 



IN 
OuT 



This API returns a pointer to an iUPnP$&rv}c& Interface on a newly 
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common to all instances of that service type. The Service Type identifier is 
stored as a private data member in the Service object. 

Querying Service Properties, Applications can query the values of 
service properties by invoking the fUPnPSen/ice::GetPropenyO method on a 
5 Service object. Internally, this method makes a call to the 
Rehydrator QueryState Varktbt&to function. 



The first two in parameters to this function supply the service 
instance specif ic Information: the HTTP verb to use and the control URL to 
which the network messages will be targeted. The third parameter is the 
Service Type identifier that will be used to locate the -Service Control 

20 Protocol information In the Rehydratot'e internal data structures, The 
fourth parameter Is the name of the variable that is being queried (the 
Rehydrator will validate this against Is internal list of state variables 
exported by the UPnP Service! and the final parameter is the address of a 
VARIANT structure In which the Rehydrator will place the variable's value, 

25 This function will generate an HTTP request to the control server on 

the device. The body of this request will be an XML fragment containing e 
XOAP-encoded request for the variable's value, The following is an 
example of such a request ithe exact header and payfoad format of this 
message is defined in the service contract}: 



P e h y o , a t ;\: Q\: e r y S 1 3 1 e V a : 
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in mcTsm 

in wcusm 

IN LPCTSTR 

IS LPCTSTR 

OUT VMIMT 



2 Z nt ~o 8 , 
XpcssSTl, 
lpcssVarMame f 
upvalue) ; 
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M-POS? /ciockSeraica HTTP /I , 1 
Host: spaiher-xeon: 858 5 
Coat eat -Type; text/xml 
Man : 

"ht. tp : / /www . microsoft . cora/oro t ocols/ext /XOAP" ; 
ns-01 

0 I-Metho d.C a ae ; qu - s 

v. o v. en-gb, en;q™QC8 

Referor : http: //syhouae/VCRlPreaentat ion 

Dssr-Aqsnt: Mo i 1 1 a / 4 , 0 (compatible; MSIE 5.01; 
Windows m 5.0} 
Connection? Keep-Alive 

< q u e r y S t a t e Va r i a fo 1 a > 

< v ar iafo ieHa;na>au rr en tT imo< / Vsr .1 abi «&airra> 
</queryStatsvariabie> 

The control server mil respond to this message with another XML 
fragment: the XOAP-srtcocted method response. The following m m 
example of such a response: 



HTTP/1, 1 200 OK 
Connection: Close: 
Cache-Control : private 
Date: Mon Oct 11 12:13:38 PDT 1999 
Expires; Mon Oct II 12:13:38 PDT 1999 
Content -Type: text/xml 
, ; 

Mao : 

"http: / /ww* ..microsoft . carry protocols /ext/XOAP" 
01~MeosageType ; CailRejjpon.se 



< return>12 : 13 : 28<V retorn> 
< / q\ • e r y S t a t e V a ; i a b . ■ . a P s a p 3 a a e > 
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The rehydrator will extract the return value from this XML fragment 
place it In the VARIANT structure whose address was passed as the last 
parameter to Pt&ftydfatorG&iServicePmp&rtyO and then return, 
5 tnyof<jSgaU.e.»F,,Servloe Actions, The process of invoking a UPnP 

Service action is very similar to querying a state variable. An application 
calls fUPnPSarvtce-lnvokeActionO on a Service object, passing It the name 
of an action to invoke, and an array of arguments to the action, internally, 
lUPnPServte&Hmok&AethnO calls RehydratortovokeServiceActlonO, 
10 declared as shown below. 

Rehydrator I) V i e.£ i.on i 



1H 


LFCTSTR 


XpcszYsrb, 


IN 


LPCfSTR 


l|3C.saeodt rolURL , 


IN 


1.PCTSTB 


IpcssSTX, 


IN 


LFCISTR 


ipc s z Act ioBNama , 


IN 


SiiFEARRAY 


ssa&ctioh&rgs, 


OUT 


LONG 


*pStatus) ; 



As was the case for querying state variables, the service instance 
specific information is passed in the first two parameters, followed by the 
Service Type Identifier in the third. The action name and an array of 
arguments are passed as the next two parameters, and the final parameter 
25 is the address of a variable in which to store the status of the operation. 

ftehydmtofhvok&Serv/c&ActkmO will send an HTTP request to the 
control server identified by the second parameter. As before, the body of 
this message will be an XML fragment containing a XOAP-encoded method 
call. An example HTTP request to invoke an action Is shown below. 

30 
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' s l'i 1 1 p : / / w vj w v m i c r o s o f t , co ift / e r o t o c o i s / e x t / XO A F * ; 
ns=01 

01-MethodNarne : invokeAcoion 

01-Mes; igeTyt e : la. I 

Accept -Language: e.n~gh t en;q-0.8 

Beferer ; hi: tp : / /my house/' VCR 1 Presentat ion 

Content -Length: 119 

User-Agent; Mozil la/4.0 i compatible; MSIB 5,01; 
Windows NT 3.0) 
Connection: Keep-Alive 

< S e r i a i i z e dS t r ears s • a i n ~ "ilwokeAcfion >! > 
< i n vo k e A c t i o n id-" invoke Act iou"> 

. i s ^- c o > ',^jk\ - k A-sno 
<a o t i onAr g> 1 5 : 4 1 % 2 9< / a c t. i onArg> 
</invokeAction> 
</ B a rial isedSt ream> 

The encoding of the body of this message is again specified m the 

service costraet. The Rehydrator will wait for the HTTP response to this 

request, which would look something lite the example below. 

HTTP/1 , 1 200 OK 

Connection: CXOs<e 

Cache-Control; private 

Date: Hon Oct 11 15:22:38 PDT 1999 

Expires: Mon Oct 11 15 t 22: 38 PPT 1999 

Content-Type: text/xmi 

si, t I V 

"hhtp: //ww. Microsoft . ccro/protocol s/e«/XOA£" ; 

Oi~MeasageType: CailResponse 

- i n v o ke Ac t i onP l o\-- 

el uri >0<7 _return> 
</invokeA.ct ior;Kssponse> 
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After receiving 8 response such as this, the Rehydrator will extract 
the return value, place it in the out parameter it was passed, and then 
return, 

5 Figures 30 through 40 are program listings defining various 

interfaces used in the preferred implementation of the Rehydrator, including 
an iUPNPDsvfce interface, an lUFNPPropeftyBag Interface., an 
iUPNPServlca interface, an iUPMPDevices interface,, and an lUPNPServices 
Interface, 

With reference to Figure 1 5. User Control Points 1 04 can retrieve a 
Description Document 228 by issuing an HTTP GET on a Description URL 
This URL is returned in the location header of either an SSDP 
announcement or an 8$DP query response. 

1 5 The HTTP GO" must include en accept-laoguage header that is used 

to request the preferred language of the response, If the requested 
language is not supported, a Description Document in the default language 
supported by the Controlled Device or Bridge may be returned. 

An HTTP GET Is used to retrieve sub elements of a Description 

20 Document that are expressed as URLs, 

URl Ha ndli ng 

URLs embedded in Description Documents 228 take one of 3 forms: 
a fully qualified URL or a relative URL, 

Fully qualified URLs take the form: 
25 http: //devicsnarne/patnnsme 
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The devieename part of the URL is a Hostname or IP address and the 
pathname is a fjlssystem path or equivalent. A fully qualified URL is used 
"as is" to establish an HTTP connection to a device. 

A relative URL does not contain the character and is of the form; 

8 pathname 
/pathname 

Relative URLS are a compact representation of the location of a 
resource relative to an absolute baee URL All relative URLs in a Description 
Document are app^^ to the value of the Description Document element 
1 0 < ORLhasa > to form fully qualified URLs. 

InarxData 

Some elements of a Description Document are binary. XML does not 
directly support the embedding of binary data, in order to include binary 
mn directly in a Description Document, one must convert the data to text 

1 8 using the Base 84 encoding scheme. This tends to increase the size of the 
data by 25% on the average. Much of this overhead can be eliminated if 
the binary data is passed by reference instead of by value. To reference 
binary data,, a URL to the data fs provided in a Description Document. The 
binary data can be retrieved by doing a HTTP GET with that URL, 

20 As an example, consider the < image. > element In the following 

Description Document: 

<iconList> 
<icon> 

25 <s :=:?.&> 1 6</aise> 

^ - Xvlc i ^clyp<^ 

<color>l</colox> 
<depr.h>e</dept.h> 
<iaage> 

30 ' xi-cp: de n :e. \ jcal/ict npatl icon, peg" ' - 
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</icon> 
</iconList> 

The icon would be retrieved with an HTTP GET of the following 
5 format: 

GET ioonpath/icon.png HTTP .1.1 
Host; device. local 

10 The HTTP response would look like: 

HTW1.1 200 OK 
Content -Type: imags/png 
Con tent -length: ### 
16 <hiaary color icon data in the PHG forma t> 

Description Document layout 

The basic layout of the Description Document 226 is shown m 
Figure 16, 

The following table lists Dasenptbn Document elements that, are 
20 sub-elements to the root element. 



Root 


The XML root 


element of a UPnP Dssj option Do un 


spacVersionM 
ajor 


this Dosoriptlo; 
must be 1 . 


iipn of the UPnP Architectural Reference that 
n Document was created against, This value 


ajor 


The minor vers 
this Description 
must be 0. 


joh of th* l>>m Architectural References that 
s* Document was created against, This value 


URLBase 


An optional ek 


me«? usu'i i k\ $ 
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create fully qualified URLs, If this element is present, $t must 
agree with the HTTP Base header. 



manul ictursr o ec {red ei< na 


SO \ ^ - 0 iOtU Oj 








URL 




modeSName \ uquiivo wuaeut 


>orf m > 0 w\iv «< v oo c' aume 


modefDescrip A required elemc 


m% conta.ung a t . ".fi't^n 


tiofi 




modefNumber An optional eler? 
number. 


lent containing a textual product model 


modelURL An optional efem 


tent containing a URL that points :.o -he Won 


page of the product,- 


UPC An optional eiam 


tent containing the product Universal 


Product Code ttJPCh 


serialNumber An optional derm 


ent coma > - < I item a rial m nber. 


The Description Documem 


i elements listed in the following table are 


associated with devices. 




tootDevu - 


n f fch r< This eierrse 


container for one 


or more service elements and the elements 


that describe the roolDevice. 
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device 


An opiu. mi St eier 

men 9 a! err 
as -3 fomQevice etenr 


sent of the root or another device 

"it contains the sanie kinds of elements 

sent. 




A required sub aiem* 
containing the Uniqu 


e Device Name, 




A squired sub eiems 
containing a textual 
updated remotely. 


s m os cvof\ rcotDevice or device element 
friendly name, This element can be 


cievieeType 


A required sub e-emc 
containing a standar. 


n vt j, r n t ;,vcc r'uii n 
atead Davfce Type Identifier. 


p? s ntat on 
URL 


An optional sub > « 
containing a Present 


?ent of a roofDeviee c > ml 
ation URL. 


iconlist 


A reaped sub > f rv >oelDovieo o ri^v 
element. This element Is a container for one or more icon 
elements. UPnP requires a base set of six icons that must 
exist in the sconUst, All devices must support PNG icon 
Image formats of three sizes, 1 8 by 1 6, 32 by 32 and 48 by 
48 pixels m both color and black and white at 8 bit depth. 
Additional formats and sizes, including JPEG,. GIF, BMP, 
ICON and VML, may be supported by adding them to the list. 


icon 


A required sub elem< 

i ; 0 nta s i 


ml of ever > * * > u Ibis 
sr for the elements that define an icon. 


size 


\ requ 1 Si « 
icon elements with « 


n o? every icon clement, There must be 
iseoclated size elements with the values 
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Icons mas > sszes. 


color 


t. Each icon of mm 18,. 32 or 48 must exist in color and 
black and white. 




A required cub eiemer 
icons must exist with 


st of every icon element. AH required 
a value of 8, 


ImageType 


A required sub sterner 
xhfi format of the bins 


it of every u - - <-a mat identifies 
ry icon: png, jpeg, vml, gsf, bmp, or ico. 



image A required sub element of every con 

a binary icon. 



The following elements of the Description Document ere associated 
with UPnP Services, 



service 


Ah optional sub eie 


' no***** Jan. 




©lament. ) nss elemr. 


s«t Is a container for the Service Definition. 


servioeTyp 


A required sub eterr 


>e«t of every se* ng 


a 


standardised Servic 


e Type identifier. 


controiUR 


A mquited sub eierr 


evoty *v» > in o - m j, 


L 


URL 




eventSubU 


A requsr ?d sub e'iem <.>er rvi < Event 


PL 


Subscription URL 




SCPD 


A required sub elerr 


sent of every service. The SCPD is a 




container for the st! 


andardfeed Service Control Protocol 
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r < < t n associated the Service, 



Figure 1? shows an exemplary scon list in a Description Document 

226. 

Service ;p Declaration 

5 As part of the Service Definition 408 shown in Figure 3. a Service 

State Table 230 and Command Set 408 are defined. The SCPD 408 is a 
representation of the scheme of a UPnP Service, ft is possible to 
reconstruct the SST 230, Command Set 408 and SCP 402 from the SCPD 
daterministieaiiy, 

10 The declaration of such a protocol must specify the list of Variables 

that can foe queried, the set of Commands that can be Invoked, as well as 
the wire protocol (the content and sequence of network messages) 
required to carry out these operations. SCPD is specified in two XML 
documents. The first or Service Control Definition document 404, written 

1 S In a language called Service Control Protocol Declaration Language 

{SCPDU, declares the list of state Variables and Commands associated 
with the Service Type to be controlled by the protocol. The second or 
Service Control Protocol document 402 declares the wire protocol thai will 
he used to query the values of the state variables and invoke the actions 

20 associated with the UPnP Service. 

' ' ,s v ? tal o - m indjSet 

A SCPDL document 404 is used to specify the list of state Variables 
that a SCP can query and the set of Commands that it can invoke. SCPDL 
is an XML schema, a set of rules for writing XML documents (Service 
25 Control Protocol Declarations), 
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Figure 18 shows an exemplary SCPDL document. This XML 
document consists of a root <scpd> element containing two sub- 
elements, <s&rvfCB$mt& Table > and <actianUst> . Within the 
< services tats Table > element is a <Met&Variabie> element for each state 
5 variable associated with the UPnP Service. The UPnP Service in this 
example is a TV tuner with has only one state variable., cwrentChmmL 
The elements within the <stat»Vatiabte> element specify the name, data 
type and allowed values for the state variable. Had the UPnP Service more 
state variables,, they would be represented by additional <$tat&Vambte> 

10 elements within the <d0vk®$'tsteT»i>!e> element. 

The <&ctlonUst> element contains an < action > element for every 
action associated with the UPnP Service. The elements within an 
< action > element specify the name of the action and any arguments the 
action may take, in this case, the UPhP Service supports two actions that 

15 do not take argument mmm/i/p and Chmm&owm and another, 
SetChanmt, that takes a new channel number as an argument, The 
<argument> element and the elements nested within it define the 
argument. The <rehtsdSmteVambie> element within < argument > 
specifies the name of one of the state variables to which the argument is 

20 related, in the UPnP Device Model,, all arguments to actions must 
correspond directly to some state variable. 

figure 19 and 20 show an XML schema for the SCPDL. 

Basjo UPnP Eventing Architecture 

With reference to Figure 21, the UPnP architecture 200 (Figure S> 
25 requires thai clients of the UPnP API be enabled to receive notifications 
reliably from UPnP services 210-217 as their states change. Since state 
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changes are relatively common, the eventing subsystem's efficiency end 
performance is a major consideration in this design. Figure 21 and the 
following discussion describe the Basic UPnP Eventing Architecture 600, 
which encompasses both the controlled device (CD) 106 and user control 
5 point, (UCP) 104 sides of the eventing UPnP Service, It also includes the 
support APIs for both a low-level UPnP Service interaction and a higher 
level COM-teased wrapper of those APIs. The latter enables automation 
controllers like Visual Basic and JScript 602 to receive event notifications. 

1 0 Property change events arc defined as any change In the value of a 

row of the Device Stats Table ID ST} 230 (Figure 5} for a UPnP Service 
210-217, This change will be reflected as a property change notification. 
For example, if a "VCR" device has a "VCR Transport" UPnP Service., one 
row in that UPnP Service's DST may be TzpeStste and the value could be 

1 S T00Pt0s&nt If the tape is elected, the » value would be T$p&Absertt. 
This state change would be reflected as a notification sent to ail 
subscribers, 

A UPnP event notification is an XML message sent over HTTP/TCP 
20 to each and every subscriber to a particular UPnP service. The content of 
the XML Is defined below- The important contents of this message are the 
unique Identifier for the subscription, the property name, new value, and 
property type. 
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in UFnP, the listener to Notifications is the SSDP service itself, 
SSDP already listens on another multicast address for "alive* and "byebye" 
messages sent by VPriP devices. The same listener will listen on a TCP 
S port for notifications sent, All subscriptions sent from that UCP contain 
the same callback URL end so all notifications will be directed to that URL 
When a notification arrives the SSDP service will examine the MT header of 
the message end determine if it is an event notification. If so ; the message 
is parsed further to determine if it should foe forwarded on to subscribers 
1 0 (which must exist!. GBHA defines the format of the HTTP message, what 
headers can be used, and what they can be used for. 

MSA 

GENA Is the protocol of communication that, in a preferred 
embodiment, UPnP devices use to send event notifications. Therefore, 
1 5 UPnP devices that wish to notify UCPs of state changes are recommended 
to use GEN A. Notification subscribers s never be required to interact 
with a UPoP device directly and so they are not required to use GEN. A, The 
eventing API will encapsulate this complexity. Other appropriate event 
transport protocols may be used, such as publish/subscribe systems, 

20 Ret ^ ■ , v 

Applications written in C (C Application 804) will be able to utilize 
the SSDP CAP! 610 to receive callbacks when notifications are processed 
by the SSDP service. This Is analogous to SSDP clients registering for 
notifications that services have become available. When a UCP registers 

25 for a notification, it passes as a parameter the URL of the UPnP Service for 
which it is interested in receiving notifications. This URL is obtained from 
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the description document for that UPnP Service. (When a UPnP Service is 
registered on a UPnP device., it uses this same OR!., to listen for 
subscription requests? . 

When a notification message is received by the SSDP service 
5 listener, the SID header is checked against the list of subscribers it 

maintains. If a subscriber is found, the callback function for that subscriber 
is invoked, with one of the parameters being the contents of the 
notification message. The notification client that Implements the callback 
function can process this message m any appropriate way. 

* 0 Notifications in the UfinP API 

The UPnP API 410 is a consumer, of the basic C interface provided 
by the SSDP C APS 61 0 component, in order to integrate seamlessly, the 
registration of notifications is handled by the Service Object 61 2 inside the 
UPnP Object Model, Service objects will register for notifications when 

1 5 they are created. This ensures that the OST is maintained by the UPnP API 
and is kept up to date. They will implement the callback function required 
by the registration function. If this callback function is invoked, it will pass 
on that notification to UCPs. The UCPs can be written in C, C + + , VB, or 
script code, so the mechanism for passing on notifications can be different. 

23 Sonet.Suoport 

A feature of the illustrated eventing system is that it supports script 
languages such as VBScript and JavaScript 602, For VBScript, this is 
made possible by providing a property on the Service object that, when 
set, contains the IDispatch pointer tot a VBScript function or subroutine 

25 that will be the event handler. When the Service object's notification 

callback is invoked, it checks to see if this IDispatch pointer was set, and if 
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so, ft cells IDispatch:: invoke on DiSPIO 0 of that Interface to call the 
VBScript subroutine. An equivalent mechanism Is implemented for JSeript. 

S^MilM Subsystem Jernrtoolo^ 

UCP - User control point, Any piece of software that searches for 
5 devices and controls them. 

CO ~ controlled device. A hardware or software device that 
announces its availability thru SSDP and allows control by UCPs. 

Subscriber ~ A UCP who wishes to be notified of event changes. 
Notifying Resource Cor simply "Resource") •• For the purposes of this 
1 0 document, this will always be a UFnP Service contained within a UPnP CD 
106, 

Event Source - a UPnP Service that provides events. UPnP services 
are event sources. All notifying resources ere event sources and vice 
versa, 

I S Event - message generated when a change In a resource's state 

occurs. 

Property - a single entry in the UPnP Service's state table whose 
Del auitValue can change. Properties and events always have a one to one 
correspondence, 

20 Suhscnhmg To P^urcgS 

The UPnP API 410 exposes several interfaces with which a 
consumer can find and enumerate devices,, control UPnP Services, and get. 
properties on devices and UPnP Services. To allow the integration of 
25 events into this model, we add a new property to the iUPnPService 
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interface called ZventHma'ter. When this property is set, it tells the Service 
object 812 that its client is interested in receiving notifications for that 
UPnP Service. The SSDP API ftegisterNotifbationO APi is called when the 
Service object is created so that it can maintain a boat copy of the DST for 
that UPnP Service. The Service object knows the URL of the UPnP Service 
and therefore it can provide this as a parameter to RagisterNotifteationO. 
RegbterhiotifbatbnO is aiso provided a callback function which is a static 
member of the Service object class. This function will be invoked for each 
and every notification sent by that particular UPnP s 



1 0 The Notification C allback 

The Service object 612 includes- a static member function called 
■BvmtNotffyCaUhackO which b invoked for each notification sent by the 
UPnP service. The callback la passed the entire HTTP massage contents in 
a structure which is a parameter to the function. The prototype looks like 

IS this: 

static VOID 

COPnPSer vice: ;Ev«sntbJotif /Callback { SSDP CftlLBlCK 
r ( ssdpT" pe, 
20 s 'ir ~ 

hPVOlD peon text} ; 

The ssttp Typ& parameter should always be SSDP_PROPCHANGE. 
The pssdpMsg parameter contains the relevant information about the 
25 event. The key piece of information Is the body of the XfvfL message. The 
body contains information about what property changed, what its new 
value is and what type it is, among ether information. The pConiext 
parameter will always be the mis pointer of the Service object. This allows 
the code to call a method to fire the event to the UCP. The callback will 
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pmm the XML body using the XML DOM services, Property changes are 
iterated and the looa! DST is updated to reflect these changes. After this 
processing is done,, an went notification may he fired for each property 
that was changed to the owner of the subscription if one exists. 
5 Depending on what environment the owner is written in (C -f -f or script, 
etc.), a different mechanism for firing the event may be employed, 

A special case for this process is the very first notification received 
after a subscription is established. This notification contains the entire set 
of properties and their values and is used to locally sync up the DST, 
1 0 Events will not be fired to clients of the UPnP API in this case. 

When the EvantNotifyCailhackO function is called, the local copy of 
the DST for the UPnP Service is updated. After this, an event needs to be 
fired if a subscriber exists. A subscriber exists if the put„EventHar*dler{) 
1 5 method was celled,, either from VBScript, C 4- + code, or another source, 
To abstract away this complexity,, a new interface celled lUPnPEvents is 
needed. 

This interface currently has one method called NotifyEventO which 
takes several parameters, When put EventHandierf) function Is celled, its 

20 argument is an (Unknown. This pointer is Guerylrrterface'dO for IDispatch 
first, and if It succeeds, then IDispatch;: invoked is called with D1SPID 0 to 
invoke the default method. This allows VBScript 802 to be called. If that 
fails, however, it is Queried for lUPaPEvents, and if that succeeds, the 
NotifyEventO method is called with the same parameters as for Invoke*). 

25 The handles C-f* UCPs effectively. 
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To subscribe to a UPnF service from C+ + , a UCP instantiates a 
UPnP service object, issues Query Interf ace 0 to it for lUPnPEvems, and 
calls the IUPnP£vents::S8tEventCalibackO function. This function takes 2 
5 parameters, a callback function pointer and a context pointer, 

S ibsci b f do lot 

To subscribe to a UPnP service's events, all that needs to be done 
by a script 602 is to create a function or subroutine as a handler function 
and set the pointer of that function to the BventHandter property of the 
10 Service object. How, anytime an event Is fired, this VBScript function or 
subroutine will be called. In VBScript, this is written as the following; 

Dim UPnPAPI 

Set UP; fc£ ] C :.c 3b s ,s t r >Pn VP . 1" ; 

IS 

Devices - UPnPAPI.FindDevices{. < » ) 
For each device in Devicee 

For each service In devices services 
If service ..depi « « clock. vl* 
20 Service, SventKandier - 

Get Rex p clock ProDertvChanqecr ) 
End™!? 
Next service 
Sij^t device 

25 

i > " ■< s 

i 1 t is now " £ 

End Sub 

30 

In this example, the script enumerates all devices, looking for any 
device that supports the "Clock" interface. When It finds a device that 
supports that interface, it enumerates that device's UPnp Services looking 
for the one that has the "eioek.vl " interface. Once it finds that UPnP 
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Service, it sets that service's SventHandtor property to the VBScript 
subroutine called "ciockJtopertyChanged*. This name is arbitrary, 

6 GEMA clients are actually UPnP services. A GEMA client creates a 

new event source when it is Initialized. The GEMA client API 820 
facilitates this, It also provides a way for GEMA clients to send their 
notification massages, it is also important to note that the HTTP server 
that lives on the UPhf device is also a client of this API, The GEMA client 
1 0 AH consists of the following functions: 

The RegisterUpnpEventSourceO API gives a GENA client the ability 

to register itself as an event source. The prototype is as follows: 

BOOL RegisterUpnpEventSourc© i 
18 l ?si i e juostOri, 

DWORD c?rops, 

M 

Parameters; szRequestUri {ml an arbitrary Request-Url that 
20 SUBSCRIBE requests will be sent to. When a SUBSCRIBE request arrives 
at the given URI, it Is acknowledged and the subscriber is added to the list 
of notif ication recipients. Note that this URI should match the URI provided 
in the description for this service. CPmps [inj the number of properties 
that m event source provides. BgPmps |inj Array of UPNPJPROPERTY 
25 structures which contain information about each property. The property 
Information Is derived from the DST for the event source. 
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Return Value: The function returns a TRUE if successful if the given 
URL hss already been registered as an ©vent source, the return value is 
FALSE and GetLastErrorf) returns ERRGR^ALREADY EXISTS. 

Motes: The initial state of the event source needs to be given to the 
5 API so that it can effectively maintain the up-to-date state of the event 
SO;.; res, 

iM^ster^^ 

The DeRegisterUpnpEventSourceO API gives a GENA client the 

ability to dereglster Itself as an event source. The prototype is as follows: 

10 VOID 'A v - . -".o r- ^ rve - - euros { 

LPCTSTR sxRequestUri 

); 

Parameters: szBeguBStUri m en arbitrary Request-Utl that 
1 5 SUBSCRIBE requests will be sent to. When a SUBSCRIBE request arrives 
at the given URi, it is acknowledged and the subscriber Is added to the list 
of notification recipients. Note that this URS should match the URI provided 
'm the description for this UPnP Service. 

20 typedef struct JOPMP PROPERTY { 

LP7STR saName; 
LPTSTR Sz Value; 
LPT STB srl'vce; 
\ UPNP PROPERTY; 

25 

Where szmme is the name of the property, szValm is the current 
value of property, end szType is the type of property (string, integer, 
etc.d- 
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Sub tUpng 1 po'v^.r j 

The SufemitUpnpPropertygventO API allows the GEN A client to 

submit a UFnP property change event to be sent to subscribers as a 

notification. The prototype Is as follows: 

5 30 Subs pnp 5rc 

FCTSTR ?. R e q u & s t U r i 
DIGGED dwFIags, 

DWORD cProps, 
ut-W PROPERTY ^-aProps 

10 J; 

Parameters; "szRequBStUri BnP Identifies the event source to which 
this event belongs. This is the same Request-Uri passed to 
BegisterUpnpEventSourceiK "Owtfrgs M* is unused. "CPmps M* Is the 
1 5 number of events that are being submitted. "RgPwps ImV is an array of 
ypMP m PROPEHTY structures which contain Information about each event. 

Return Value: If the funotion laffs, the return value is FALSE, The 
get extended error Information, call the GetLastBrmn'} function, 

botes' When a series of properties Is submitted for went 
20 notification, the local version of the property state for the given event 
source is updated with the list of properties passed in, 
SubmitUpnpPropertyEventf) calls SuhmitEverrhj after it has generated an 
XML body. 

Sp^n^ventO 

25 The SubrnitEventi) API allows the 6ENA client to submit an 

unstructured event to be sent to subscribers as a notification. The 

prototype is as follows: 

BOOL Submit Svexit ( 
EPCTSTE ssReq-usstUri , 
30 DWORD dwFIags, 
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LPCTSTR szHeadsrs f 
LPCTSTR s z KventSodv 

i; 

Parameters: SzftequestUri IN identifies the event source to which 
5 this event belongs. This is the same Request-Uri passed to 

RegisterUpnpEventSoureelL Dwfiags On] Unused. SzHeadets On! null- 
terminated text string containing the headers for the event,, each separated 
by CRLF. SzEventBody \m\ null-terminated text string containing the body 
of the event message 
1 0 Return Value: if the function fails., the return value is FALSE, The 

get extended error information,, cali the Gettast&rorQ function. 

Notes: if no subscribers exist,, the function does nothing. If one or 
more subscribers exist,, a message Is sent to each subscriber. 
SubmltEventO m always send to all subscribers. 

ts Ugnf ControflsdJSavtce Event Architectotf 

in UP«F t every UPnF service 210-21 1 that supports property change 
event notifications is to be a GENA client. Therefore, when the UPnP 
Service is Initialized., it must register itself as a GENA event source. It will 
do this with the RegisterUpnpEventSourceO API. This returns a handle 

20 which can be used In subsequent APIs, 

fiflgisterUpnpEvQntSourceO takes a URL and an array of properties as 
parameters, inside the API, an entry in an array of structures is initialized 
and the index is returned as the handle. The structure contains the source 
URL as one of the members, A second member of the structure, an array 

25 of destination URLs, Is left uninitialized. This is filled in each time as 
subscriber is <idded for thai event source. Another member of the 
structure is the list of properties that this event source provides. This is 
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effectively a cached copy of the OST for the event, source. As events are 
submitted, the local properties are updated. 

When SubmitUpnpPropertyEventO is called,, each property submitted 
replaces the corresponding property already maintained by the API If no 
5 subscribers exist, the request to submit an event is ignored, if one or more 
subscribers exist, their callback URLs are looked up in the list of 
subscribers for the given event source and a NOTIFY message is 
constructed and sent to each URL, one at a time, in order of subscript^. 
If an event is submitted and no response is received for a CD-side 

10 error occurs},, the CD continues to attempt to send to the UCP. If the 

subscription timeout expires, then the subscription is removed. If the UCP 
becomes available again, it will re-subscribe because it wiii notice the 
sequence numbers are not contiguous. 

When an HTTP server 620 receives a SUBSCRIBE message, it passes 

1 5 it along to a function which parses the message for the necessary 

Information, The Raquest-URi identifies the UPnP Service that is to be 
subscribed to, The callback URL is obtained from the "Callback* header. 
Since the Callback header can contain multiple URLs, it picks the first 
"http;//" URL it finds. St then adds the subscriber to the fist of subscribers 

20 for this event source, A unique subscription identifier is constructed which 
it will send back to the subscriber in the HTTP response to the SUBSCRIBE 
request. 

If no event source matches the RequesMlRl from the subscription 
message, the HTTP server should return "404 Not Found", 
25 When a subscription Is added,, the local copy of the DST is sent as a 

NOTIFY message. This special NOTIFY message contains sequence 
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number 0 which informs the OOP that this is an initial state population 
event and not a notification where every event has changed. 

When a CD receives an UNSUBSCRIBE message, it cheeks the *StD" 
header to obtain the subscription Identifier, it looks up the subscriber ID in 
5 the list of subscribers for that event source and removes the destination 
URL entry associated with it. 

QgMJMverAPI 

GKNA servers 830 are generally going to be UPnP UCPs, A GEN A 
server is anything that receives and processes NOTIFY messages to handle 
1 D notifications from resources and sends SUBSCRIBE and UNSUBSCRIBE 

messages to receive notifications from resources. These APIs leverage the 
already existing SSDP APIs.. The following are the changes to the APIs: 

The RegisterNofifloationi} aifews a WnP UCP to request notification 
1 5 when en event occurs for a given UPnP service. The prototype is as 
follows; 

HAN DLF Reg i a . -Not 1 1 i cat i on ( 

NOT! FY TYPHI ot f /"/ SPDP_M:JVE ) 

20 LI 4 /'/ based on 

NOTIFY TYPE, unused if 
// SSDP PR0P;mNGF is used. 
} ( 

ex OackFunc fnCaliback, 

25 to id *pContext 

>; 

Parameters,: M On] An enumeration that determines the type of 
notification requested. The values are: S3DFAUVE ~ o UPnP Service has 
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become available, and SSDP_PRGPCHANGE ~ a property has changed on 
the UPnP Service. S^ResoufceTyps fin] A null-terminated string specifying 
the resource type desired, For SSDRALIVE, this is the service type, for 
SSDP PROPCBANGE this is unused, SzEventUrf fin] A null terminated 
5 string specifying the URL that a subscription request should be sent to. 
FnCafiback \m\ A pointer to a function that will be called each time a 
notification is received. The function pointer is defined in the SSDF spec, 
PCom&xt [ml This parameter is included as a parameter when invoking the 
client-supplied callback, function. 
10 Return Value: If the function succeeds, the return value Is a handle 

used In a subsequent call to the DeregistcrEventMotificafionO function, if 
the function falls, the return value is INVAUD ra HANDtE VALUE error coda. 
To get extended error information, eall tSetLastErrer, 

16 typedef ecus S S D P__C >\L L BA C K TYPE f 

SSDP~ALT.VE - 1, 
P > 

DONE - , 
20 SSPp'_?ROPCHAKGP =- - . 

1 v ' ■ ■ ■ ■ , ' 0 T 

mn? mp Architecture 

When a UPnP UCP wishes to subscribe to notifications for a 
25 particular UPnP service, It ceils the ReglsterNotificatlonO API. It passes to 
this API a notification type that identifies the type of notification being 
raq«ested> a URL to which a subscription should be sent, and a callback 
function and context for use when the notification is received. 
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RegisterNotlfieationO will compose a SUBSCRIBE message., using the 
data passed in, and send that to the URL specified by the caller. The 
Callback header of the SUBSCRIBE message will be composed en the fly, 
es an arbitrary URL for notifications to foe sent to for this subscription. 
5 This callback URL will likely be a constant since the server API will always 
know how to handle requests sent to this URL. It will then sand the 
SUBSCRIBE message and await a response. 

RegistarNotifieationO in the SSDF API does not currently send HTTP 
requests, but it can be modified to do .so, ft also needs to await a response 
1 0 which it will also be modified to do so,. 

When the response is received, the Subscription-ID header contains a 
SID which is associated with the callback function specified by the caller. 

Immediately after the response is received, the UCP should expect 
an initial NOTIFY message that contains the complete set of properties 
1 S maintained by the CO, This becomes the local cached DST on the UCP 

side, From this point on, all modifications to the table are made via NOTIFY' 
messages. This initial NOTIFY message will have sequence number 0 that 
indicates it Is an initial property set and not an update. The UCP can use 
this information in any way it sees fit. This ensures the UCP's state table 
20 is always in sync with the one on the CD. 

When a message is received by the HTTP server on the UPnP UCP,. it 
is passed to a function which determines the method name and Request- 
URL If this is a NOTIFY message, the headers are parsed and packaged up 
info a structure. The callback function that was specified to 
25 RegistenMotificationO Is called with that structure as one of the parameters, 
UCPs who implement the callback function can find the headers and body 
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of the NOTIFY message and do additional processing based on the 
no tin c a 1 1 o n typo « 

This all requires that the SSDP HTTP server listen on a TCP socket in 
addition to the UDP multicast port it already listens to, However, ones a 
5 NOTIFY message is received,, it is processed in the same way regardless of 
f om hi i n nginated 

The following are subscription/notification failures that can occur and 
their solutions' 

To protect against subscriptions that exist oil the controlled device, 
but no longer on the UCP, we institute the timeout feature of QMUA 
subscriptions. The scenario is this; A UCP subscribes to a CD, then the 
UCP reboots. Meanwhile, the CD Is still trying to send notifications to that 

1 5 UCP. if the UCP never comes back, the subscription would be leaked 

because the UCP never told the CD that it was going away. So to correct 
this, each subscription request includes an arbitrary tlmaout value which 
indicates to the CD that the UCP will be re-subscribing every n seconds 
indicated In the timeout header of the subscription request, If the timeout 

20 expires on the CD, the subscription is removed. The UCP is required to re- 
subscribe before the timeout period has elapsed. If it fails to do so, the 
subscription will be terminated by the CD, 

Some time before the timeout expires on the UCP, a re-subscribe 
message should he sent. The re-subscribe message is similar to the 

25 subscribe message, but it does not contain an NT or Callback header, if 
the UCP is unable to re-suhscribs within the timeout period, the 
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subscription will be terminated fey the CD, If the UCP sends a re-subscribe 
after the CD has terminated the subscription., the CO will return "412 
Precondition Failed", 

BgteLQf^ Control?ed Device 
8 if a controlled device reboots, information about alt of its subscribers 

would be lost. To prevent this, the subscriber information will be persisted 
across reboots of the device. Because the subscription info contains a 
timeout member, the absolute expiration time will be used when the 
subscription information is persisted. That way, when the device comes 
1 0 back up, it can check the timeout for each subscriber and if that time has 
passed,, the subscription will be removed, 

If a controlled device receives an error sending an event notification 
to a subscriber, it will NOT cease to send notifications, it will continue to 

15 send notifications and receive errors until the subscription expires. The 
problem for the UCP is that it will have missed a number of event 
notifications and so its state table will be out of sync, To correct this, 
each event notification message will contain a 32-bit sequence number that 
starts at 0 end Increments for each message sent to a subscriber, if a 

20 subscriber receives a notification with a sequence number that is not 

exactly one more than the previous notification., it will know that it has lost- 
events and will ignore ail future notifications until it receives one with 
sequence number 0 again. Events with sequence number 0 indicate that 
the event is an "initial state" event. 

25 Once It realizes that is has lost one or more events, the UCP will 

send an UNSUBSCRIBE message, followed by a SUBSCRIBE message. This 



is not the same as a re-subscription because ^subscriptions do not causa 
the CD to start the sequence over at 0. in this case, the active 
unsubscribe/subscribe wilt cause the CD to restart the sequence at 0 and 
send the entire state table with the first notification message. 



When a UPnP UCP wishes to subscribe to event notifications for a 
UPnP service 210-21 1 , it will form a SUBSCRIBE message of the folio wins 



3 U 8 S C R 1 S E s e rv i ce I HT T F / 1 . 1 
10 Host? vet. local; 200 

\t : ;, \ : . , 

Callback; <http: //tamotel > local ; 923/upnp> 
Tiiseout: Second-600 

1 8 The response is as follows:; 

HTTP/ 1.1 200 O.K. 

SID; uuid;kjSd4faa~7dec-lld0-a765-00a0c$Ie6bf6 
Timeout; Second- 600 

20 This example of a Gi&A SUBSCRIBE request and response 

demonstrates a subscription to event notifications for "service 1 /' The host 
is "verJoeaL" Ail notifications for this UPnP Service will be sent to the 
callback URL http://remot«1 Jocal;923/upnp. In the response, the 
"Subscription-ID* header provides the subscriber with an Identifier to use 

25 when it wants to unsubscribe to this resource. The "Timeout" header 

indicates that the subscriber will send a re-subscription request before 1 0 
minutes have elapsed, if the device does not receive this request within 
that period of time, it will remove the subscription. 
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When a UPnP UCP wishes to re-subscribe to event notifications for a 

UPnP service, it will form a SUBSCRIBE message of the following format; 

SUBSCRIBE service! HTIP/l.I 
S Host; ver, local: 200 

S 1 D : uuicl : kj 9d4 f ae - 7dec~ 1 160 -a 7 € 5 ~ C 0a Oc 91 e Ob.t 6 
Timeout : Second-- 60 0 

The response would be as follows:: 
10 HTTP/1,1 200 O.K. 

SID; ouxd: R j Sci4f ac~7oec~1100~a'; 05 -•OOaOc^leObt 0 
Timeout: Second- 600 

Note that the UJ and Callback headers arc absent, but tile SID 
15 header exists- This tells the CD 106 which subscription Is being renewed 
and restarts the timeout When the CD receives this message, it will 
persist the subscriptions to disk {or other persistent data storage medium), 
updating the absolute timeout based on the current time and a new timeout 
sent by the UCP |if It was different}, 

20 The NOTIFY Message 

When a resource wishes to send an event notification, it will form a 
NOTIFY message of the following format: 

HOT I FY upnp RT!K\/Xv 1 
25 Host: remote 1. local: 92 3 

SID; o a 'id ; .k 1 9 d 4 f a - 7 da c ~ 1 1 d 0 - a 7 0 5 - 0 0 a 0 c 9 1 e Ob f 6 

30 Content-Length: <\ . k 

Content -Type : text/xml 

<event XML- soheraa> 

35 The response is as follows;; 
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HTTP/1.1 200 O.K. 

This example of a CaEMA HOTIP V request and response demonstrates 
that a "upnp:propertychanged ff event Is being sent to 
8 http;//remote1 Jocal;923/upnp. The USN header identifies "vcr.servicel "" 
as the event source. The XML contains the property name., value, and 
type. The *Seq" header indicates the sequence number of the notification. 
Sequence number 0 indicates the initial state update for the subscriber, 

Property Chang e Event XML Schema 
10 A UPnP property change event will be of the following form: 

<0: proper tyeet xsslns : 0^^p*> 
<rj t propcount>2</0 : propcourit> 

18 <U:£oo> 

<xj t type>*t ring</0 : type> 

</U: proper ty> 
20 <U; property > 

<U:bar> 

<0 -. type>inteoer< /U : tyoe> 

2? 

</U:foar> 
2§: </U:property> 

</U;p£Ope.rtyset> 

Here., a property named "too" is of type "string''' and has a value of 
"goodbye" and a property named "bar" has a type of "integer" and has a 
30 vaiue of 27, The XML will be contains a list of multiple properties that 
have changed, along with a count to make it easy to determine this. 
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The um Message 

When a UPnP UCP wishes to unsubscribe to event notifications for $ 
UPnP service, it will form an UNSUBSCRIBE message of the following 



UNSUBSCRIBE service! HTTP/1 - i 
Host: ycr. local: 200 

S o , , v o * - — , ' - , »c 

The response would he as follows:: 

HTTP/1 , 1 200 0>k> 



This example of a GEM A UNSUBSCRIBE request, and response 
demonstrates that the UCP Is no longer interested in receiving event 
notifications from http://vcr. local/service 1 :200. 

15 §Ml3L§tep: UCP |ojC^,&Bgok 

This section will take a step by step approach to what happens on 
both sides iiSCP & CD} of an event notification. The description starts at 
the initialization of a UPnP device. Figure 22 illustrates the subscription, 
notification, and unsubscdptlon process. 

20 

1 , A UPnP device celled "vcr" Initiates. 

a. it sets itself up to be an HTTP server by doing the following: 
L it binds to a TCP socket using its IP address and an arbitrary 
port number. This address/port pair will be referenced by all 
25 incoming URL requests. 

si. It listens for incoming connection requests on that socket and 
sets itself tip to accept any Incoming connections, 
h, it sets itself up to be an HTTP client by doing the following: 



I Calls InternetOpsnO to get a handle to the Internet session 
c. For each UPnP Servfee it exposes, it does the following: 

I, It calls the SSDP API RegisteFUpnp£yentSourceO to let the 
SSDP server know that it will be accenting subscriptions and 
sending event notifications. At this point, It has no 
subscribers, Mote that this is called before the DPn? Service 
has announced itself so that it can he ready to accept 
subscriptions immediately, RegisterUpnpEventScurceO sends 
no network traffic on the wire. It is a local initialisation only, 
RegisterUpnpEventSoareeO does the following; 

1 . Adds a structure to the list of event sources containing 
the following; 

a. A URL to which s 



I S b, A list of destination DHLs. A notification r 

will he sent to each destination URL, 
c.The state table for the event source.. This structure 
contains the property name, value,, and type for 
each property supported by the UPnP Service, 
20 if. It calls the SSDP API BegisterServlcei) to let the world know 

that it has become available, RegisterServieeO will send out ar 
SSDP "alive* message on the multicast channel that will be 
heard by any device running the SSDP service, 
d. St starts sending events immediately, even without subscribers. 
25 Each event submission updates the focal state tabic. This 

submission needs to be atomic with regard to adding subscribers., 
so between the time the SubmitEventO API is called, and the time 



*> can be 



2, Meanwhile, a UPnP UCP initializes. 

a. It initializes its HTTP server, passively listening on a TCP port. 

b. if the UCP started up before the UPnP device initialized, It won't 
see any services become available.. When the device finally starts, 
the UCP will foe notified. 

c< Once the UPnP services have been announced the UCP will be able 

to access one or more of them. 
&. The UCP drives the UPnP API to instantiate s UPnP Service Object 
e. The UPnP Service Object does the following when it is 

instantiated; 

i. It obtains the event subscription URL from the description for 
that service, 

P. it calls the SSDP API ReglsterNotificationO specifying 

SSDPJPROPCHANGE as the event type,, the event subscription 
URL, a callback function pointer (which is 3 static member 
function of the class), and a context pointer (which is the 
"this" pointer of the class), RegisterNotificatianO does the 
following: 

1 . It makes an LBPC ceil to the SSDP service. The rest 



2, If this Is the first time It Is ceiled for 

SS D P PRO PC HANG E notifications, ReglsterNotificationO 
will call InternetOpenO to get a handle to an internet 
session. This handle is shared among all local UPnP 
UCPs. 
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3. It calls -inteinetConnectO passing the server name given 
in the URlltwas passed. 

4. it calfs HttpOpenRaquestO passing In the rest of the URL 
it was passed 

5 8, The handles returned by these functions are saved with 

the structure that maintains the subscription. 

8. it composes a SUBSCRIBE message, using the date 

the "NT*, "Callback*, and Timeout" headers. The 
1 0 Callback header of the SUBSCRIBE message will be 

composed on the fly,, as an arbitrary URL for notifications 
to be sent to for this subscription. The server name is the 
local IP address, and the port Is the same one referred to 
by step 2a shove. 

1 5 7 . h calls HttpSendRequestl) to send the request to the 

CD- This Is a synchronous function that will mtum when 
the mqmst has beers responded to by the CO. 

5. It calls HftpGusrylnfoC..., HTTP QUERY^CUSTOM, .-.<) to 
get the ''Subscription- Id" header. The resulting SID will 

20 be stored with the subscription structure. 

9. It ealls HttpQuerylofoh.., HTTP _QUERY_CUSTOM, .-.} to 
gat the "Timeout" header, The resulting timeout value 
will fee stored with the subscription structure, 

10. A timer Is started for re-subscription based on the 
25 timeout value returned in the response. When the timer 

goes off, the re-subscription will be sent. 
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1 1 , The S!D, callback function pointer,, and timeout 
values are stored in a structure that maintains the list of 



3. Back on the UPnP CD, the subscription request is received by the I- 
5 server. The following occurs: 

a, The request is parsed into UBf, NT, Callback, and Timeout fields. 

b, The NT field must match "upnp:*stmt\ if it doesn't., the CD 
responds with "41 2 Precondition Failed," 

c, The UHi identifies the event source. The URi is converted into a 
1 0 URL and matched with the list of event sources registered on the 

CD. If no match is found, the CD responds with "404 Not Found", 

d, If a match Is found, the following occurs: 

I, The Callback URL is mkied to a list of subscriber URLs, 
Ik The Timeout value Is processed and an absolute time is stored 
1 5 with the event source data. If this time expires and a re- 

subscribe message has not been received, the subscription is 



lib A new SID is created, and stored with the subscriber in the 
event source, 

iv. A sequence number is initialized to 0. 

v, A subscription response is composed, Including an echo of the 



vt The response is sent, 

vii. If the response is sent successfully, the list of event sources is 

persisted to disk for recovery purposes, 
viiL A timer is started using the same timeout value as the header 

echoed to the UCP. When this timer elapses, the subscription 
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h removed, if the CD receives a re-subscribe request, this 
timer will be reset, in an idea! world, the timer will never 
elapse. 

An initial event notification is sent to initialize the OOP's state 
table. The following describes that process: 

1 . InternetOpenO is called if an existing Internet session 
handle does not exist. 

2. InternetConoectO is called,, passing the server name 
spoeified m the callback URL for this subscription, 

3. HttpOpenRequestO is called,, passing in the rest of the 
callback URL 

4. A NOTIFY message Is composed, using the data passed 
m , by calling HttpAddFtequestHeadersO . It adds the * NT*, 
"NTS", "SID", *Seq", "Content-Length", and "Content- 
Type* headers, 

a.The NT header will always ha *«pnp:event*. The 
NTS header will always be "UPnP: property-change '\ 

h. The SID header contains the SID stored In the 
event source structure 

o,The Sag header will always ho 0. 

d. The Content- Length header will be the number of 
bytes in the XfViL body. 

e. The Content-Type header will always be "text/xroP, 

f . The body of the message is composed from the list 
of properties stored within the event source 
structure; 

L Write the <propertyset> opening tag. 



», Write tha <propeoum>.o</propcount> tag, 

Where is the number of total properties. 
Ill for each property: 

i. Write the < property > opening tag. 
2* Write the <pmp> opening tag,- where 

prop m the name of the property, 
3> Write the < type > type < /type > tag,, 
where type is the stringized type name of 



1 0 4, Write the pmpm^ value.. 

5, Write the <iprpp> closing lag, 

6, Wrrtetha < /property > closing tag 
iv, Write the </propertyset> closing tag 

5. It calls HttpSendRequestExO, then internetWriteRleO, 
I S then HttpEndfiaqueatO to send the request to the CD, 

6. The response Is ignored except for debugging purposes, 
4, The UPnP CD now is ready to send an event notification, it does this by 

calling the SubmitUpnpPropertyEverrtl) API. The fallowing occurs inside 
that API; 

20 a. The event source handle Is converted to an event source structure, 

b, The properties that have changed as a result of the event are 
passed into the function and updated in the local list of properties 
stored with the event source, 

c. For each subscriber, the following occurs: 

I. imemetCoenectfi is called,, passing the server name specified 
in the callback URL for this subscription. 



HttpGpenRequestO is called, passing in the rest of the callback 
URL 

A NOTIFY message is composed, using the data passed in, by 
calling HttpAddBequestHeadersO, It adds the "NT", "NTS", 
"SID", "Seq% 'Content-Length", and 'Content-Type' headers. 
1 < The NT header will always be "upnpievsnt*. The NTS 
header will always be "UPnPrpropertychangs", 

2. The SID header contains the SID stored In the event 
source structure 

3. The sequence number for the event source Is 
Incremented and the Seq header is created with this 
value. 

4. The Content-Length header will be the number of bytes 
in the XML body. 

5. The Content-Typo header will always be "text/xml". 

6. The body of the message is composed from the list of 
properties stored within the event source structure: 

a. Write the <propertyset> opening tag. 

b. Write the <propoount>n</propeownt> tag. 
Where n is the number of total properties. 

c. For each property that has been submitted: 

i, Write the < property > opening tag, 

& Write the <pmp> opening tag, where prop is 

the name of the property, 
ill. Write the < type > type < /type > tag., where 

type Is the stringized type name of the 

property type. 



fV, Write the property value, 
v. Writs the <fprop> closing tag, 
vi Write the < /property > closing tag 
Write the </propertyset> closing tag 
5 iv\ SubmitEventO is called,, passing the event source handle, the 

handle to the headers created by 4c(i} thru 4c(iii} above, and 
the body created m step 4c{ai)6. SubmitEventO does the 
following: 

1 , It calls BttpSendRequestExO, then intemetWritePileO on 
16 the body, then HttpEraffiequestO to send the request to 

the CD. 

2. The response is Ignored except for debugging purposes. 
5, The UPnP UCP receives the notlfieation message. The message is 

processed as follows; 
15 a. The HTTP server receives a NOTIFY message with a Bequest-URI 

and several other headers, 
b. The NOTIFY message is parsed, looking at the "NT* header first, 1! 
this header contains "upnp:evenr v f then the message is further 
processed for event notifications as follows: 
20 h The message is parsed for the NTS header. If that contains 

•upnp:propertychanged", then the message is parsed further 

1 < The message is parsed for the SID header, The SID 
indicates to the UPnP control point which subscription 
2§ this message applies to> 

2, The message Is parsed for the "Sag" header, if this 
header contains a value of 0, the UCP knows this is an 
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initial state populate request. If the local sequence 
number is exactly one teas than the Saq header, the focal 
sequence number is updated (incremented), and the 
message is processed further. 
§ 3, The Requesf-URI can be ignored, since the HTTP server 

knows ail NOTIFY messages with an HT header of 
"upnp:event* are sent to the seme Request-URL 

4. If the Seq header contains a number that is not exactly 
one more than the locai sequence number, the UCP 

10 knows it has missed an event, in this state., it needs to 

unsubscribe and re-subscribe to the event source in order 
to re-sync Its state* 

5. The SiD is matched against the list of subscriptions 
maintained on the UCP, When the SID is matched,, its 

1 8 associated callback function is invoked. 

6. The callback function Is passed an SSDP„MESSAGE 
structure which contains all the relevant headers and the 
body of the XML message received. 

7. The callback function is implemented by the UPnP API, 
20 as a static member of the Service object. When this 

function Is called,, the following occurs: 

a. The body of the message is parsed using the XML 
0GIV1 services. 

b, As properties are enumerated, their values are 

2B stored In the local state table for the UPnP Service, 
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c.An event is tired to aM high-level clients of the UPnP 
API, This event contains the list of properties that 
have changed and their new values. 
6, The re-subscription timer for one of the UCPs subscriptions expires. The 
S following occurs; 

a. A re-subscribe message is composed. This message is very similar 
to a subscribe message except in doesn't include an MT or Callback 
header, but it does have a SID header, 
b< The request is sent to the CD. 
10 e. The response contains the new timeout value, 

d. The timer is reset with this timeout. 

CD^^edNeedsS^c mrthod 

This method begins with the; CD sending its initial state to the 
1 5 subscriber the first time an event is submitted by the UPnP Service. UCPs 
will subscribe to the UPnP Service first, then receive notifications for 
events as they occur. The first event will happen to he the initial state of 
the UPnP Service. The UCP state table will always be in sync with this 
method. 

20 When the CO sends a notification to a subscriber end receives an 

error. In this case, it marks the subscriber as "NeedsSync" and the next 
time an event is submitted, ail events are sent to the subscriber. The 
problem with this is that the API needs to keep track of which subscribers 
need syncing and which ones do« , t. The client of this A Pi (the UPnP 

25 service) would need to send separate messages to each subscriber and 



know which ones needed all events and which ones just wanted the ones 
that changed. 

This method states that the UCP should subscribe to event 
S notifications., then call a function that obtained the state from the UPnP 
Service. This means that any events that were received in the meantime 
would need to be matched against the incoming set of events and replaced 
if they were older. This method leads to synchronization issues where the 
UCP may receive events that are newer but when It queries for the state, it 

1 0 gets an older view of the table. This requires using sequence numbers to 
determine which information Is newer. If the view of the table received by 
the query is too old, it has to he discarded. Alternatively, the properties 
that were not received by event notification would not be overwritten., but 
ail other properties would be. Using sequence numbers make this more 

in coffipHcaieo. 

I >n v * s >t 

This preletmd method takes a simpler approach. Any time the UCP 
subftcribes to a UFnP Service, the UPnP Service will immediately 
afterwards, send the entire contents of the state table with the first 

20 notification. This precludes the UCP from making a query for the state 
table. Subsequent events update the local state table on the UCP. If the 
connection is lost, the UCP will loss its subscription, if the UCP realises it 
has not received an event after a certain amount of time has elapsed, it will 
re-subscribe. At that point, the CD will re-send the entire state table again.. 

25 and the UCP is ensured to be up to date. 
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Figure 23 and the following discussion are iRtended to provide a 
brief, genera) description of a suitable computer which may be used in the 
above described UPnP device control model This conventional computer 
5 820 (such as personal computers, laptops, palmtops or handheld-PCs, set- 
tops, servers, mainframes, and other variety computers) includes a 
processing unit 821 , a system memory 822, end a system bus 823 thnt 
couples various system components including the system memory to the 
processing unit 821 , The processing unit may be any of various 

10 commercially available processors, including Intel x80, Pentium and 

compatible microprocessors from Intel end others, including Cyrix, AMD 
and Nexgan; Alpha from Digital; MIPS from MIPS Technology, NgC, IDT, 
Siemens, and others; and the PowerPC from IBM and iVtctoroia, Dual 
microprocessors and ether multi-processor architectures also can be used 

1 5 as the processing unit 821 . 

The system bus may be any of several types of bus structure 
including a memory bus or memory controller, a peripheral bus, and a local 
bus using any of e variety of conventional bus architectures such as PCI, 
VESA, AGP, MicroChannel, ISA and EISA, to name & few. The system 

20 memory includes read only memory (ROM) 824 and random access 

memory (RAM) 825, A basic : input/output system {BIOS}, containing the 
basic routines that help to transfer information between elements within 
the computer 820, such as during start-up, is stored in ROM 824. 

The computer 820 further includes a hard disk drive 827, a magnetic 

26 disk drive 828, e.g., to read from or writs to a removable disk. 828, and an 
optical disk drive 830, e.g., for reeding a CD-ROM disk 831 or to reed from 
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or write to other optica! media. The hard disk drive 827, magnetic disk 
drive 828.. and optical disk drive 830 are connected to the system bus 823 
by a hard disk drive interface 832, a magnetic disk drive interface 833, and 
an optical drive interface 834,, respectively. The drives and their 
S associated computer-readable media provide nonvolatile storage of data, 
data structures, computer-executable Instructions,, etc, for the computer 
820. Although the description of computer-readable media above refers to 
a hard disk, a removable magnetic disk and a CO, If should be appreciated 
by those skilled in the art that other types of media which are readable by a 

10 computer, such as magnetic cassettes, flash memory cards, digital video 
disks, Bernoulli cartridges, and the like, may also be used in the exemplary- 
operating environment, 

A number of program modules may be stored in the drives and HAM 
825, Including an operating system 835, one or more application programs 

1 5 835, other program modules 837, and program data 838, 

A user may enter commands and information into the computer 820 
through a keyboard 840 and pointing device, such as a mouse 842, Other 
input devices (not shown) may include a microphone, Joystick., game pad,, 
satellite dish, scanner, or the like. These and other input devices are often 

20 connected to the processing unit 821 through a serial port interface 848 
that is coupled to the system bus, but may be connected by other 
interfaces, such as a parallel port, game port or a universal serial bus 
(USB), A monitor 847 or other type of display device is also connected to 
the system bus 823 via an interface, such as a video adapter 848. In 

25 addition to the monitor, computers typically include other peripheral output 
devices (not shown), such as speakers and printers. 
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The computer 820 operates m a networked environment using 
logwal connections to one or more remote computers, such as a remote 
computer 849. The remote computer 849 may be a server, a router, a 
peer device or other common network node, and typically includes many or 
5 all of the elements described relative to the computer 820, although only a 
memory storage device 850 has been illustrated in Figure 2.3. The logical 
connections depicted in Figure 23 include a local area network (LAM) 8S1 
and a wide area network (WAN) 852, Such networking environments are 
commonplace in offices, enterprise-wide computer networks,, intranets and 
10 the internet. 

When used in a LAN networking environment, the computer 820 is 
connected to the local network 861 through a network Interface or adapter 

853, When used in a WAN networking environment, the computer 820 
typically includes a modem 854 or other means for establishing 

15 communications (e.g., via the LAN 851 and a gateway or proxy server 
855} over the wide area network 882, such as the internet. The modem 

854, which may be internal or external .. is connected to the system hue 
823 via the serial port interface 848. in a networked environment, 
program modules depicted relative to the computer 820., or portions 

20 thereof, may he stored in the remote memory storage device, it will be 
appreciated that the network connections shown are exemplary and other 
means of establishing a communications link between the computers may 
be used. 

In accordance with the practices of persons skilled in the art of 
25 computer programming, the present invention is described below with 
ts vi - vyrvoo - on n o of operations that are 
performed by the computer 820, unless indicated otherwise. Such acts 
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and operations are sometimes referred to as being computer-executed, it 
will be appreciated that the acts and symbolically represented operations 
include rhe manipulation by the processing unit 821 of eh clrh a signals 
representing data bits which causes a resulting transformation or reduction 
5 of the electrical signal representation, and the maintenance of data bits at 
memory locations in the memory system {including the system memory 
822, hard drive 82?,. floppy disks 829, and CD-ROM 831} to thereby 
reconfigure or otherwise alter the computer system's operation,, as well as 
other processing of signals. The memory locations where data bits are 
1 0 maintained are physical locations that have particular electrical, magnetic, 
or optical properties corresponding to the data bits. 

.Bg«.raa-24.-aiKi : 28 are intended to provide a brief, general description 
of a suitable embedded computing device 900 which may foe used in the 

I S illustrated implementation of the invention. The embedded computing 

device 900 can be any variety of device incorporating electronics to control 
operational functions (operational circuitry 906), and in which computing 
and networking capabilities are embedded. For example, devices in which 
>mi * id t working functions can be embedded include 

20 communications devices {e.g., telephones, cell phones, audio and video 
conferencing systems, 2- way radios, etc.), office equipment (printers, fax 
machines, copiers, dictation, etc.), audio-video equipment f audio and video 
recorders and players, including televisions, radio receivers, compact disk 
(CD), digital video disk {DVD), camcorders, etc.), e* - t devices 

25 {set-top boxes, game consoles, etch, environment control equipment 

(thermostats, heatfng/ventiiation/alr-conditioning equipment light switches, 
etc), security systems, home appliances {coffee makers, dishwashers, 
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clothes washer/dryer), automobiles, public facilities equipment (signs, 
traffic signals, et»4 manufacturing aqyipment, and many others. 

With reference to Figure 24, the device 900 includes a processing 
unit 902, and a memory 904 to provide embedded computing capability, 
5 The processing unit 902 has hardware interfaces to the operational 

circuitry 908 thai operates devices functions. The processing unit 902 part 
be a microprocessor or micro-controller, such as are available from Intel... 
Motorola., mm, and others. The memory 904 preferably incorporates RAM 
and ROM to hold software and data for basic operating code as well as for 

The device 800 also includes a network adapter 903 for connecting 
with a network media 910 that is interconnected with the computer 
network in which the authoritative names registry (described below) Is 
implemented in accordance with the invention. The network adapter 808 

16 can be a network interface bard (or chip set integrated on a single board 
with the processing unit 902) appropriate to the particular network media 
910, The network media can be any of various wired or wireless network 
media, including Ethernet, IEEE 1394 |a,k,a. firewireb radio frequency 
including satellite, cell, pager, commercial signal sideband, etc.), power 

20 line carrier {PLC}, phone line, and television cable, among others. 

With reference now to Figure 25, the embedded computing device 
100 {Figure 24} has a software architecture 1 20 that conforms to the 
above described UPnP device control model. UFnP provides a mechanism 
for the embedded computing device to operate in the Internet, as well as 

25 networks that have no administrator and no connection to the Internet, and 
hence no access to configuration services like the Dynamic Host 
Configuration Protocol (DHCP). DHCP is a mechanism for providing 
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devices with configuration information needed to access the internet. The 
mechanism functions through the use of a multicast request for 
configuration information that is generally responded to with an IP address 
and DNS server location, Additional information can only he returned in the 
8 response. 

In non-configured (ad-hoc) networks, UPnP uses the AutoiP protocol, 
AutoiP is an enhancement to DHCP that allows devices to claim IP 
addresses in the absence of a DHCP server or similar IP configuration 
authority, IP addressee are claimed from a reserved range that is not 

10 allowed to foe transmitted on the open internet; thus they are only good for 
the local network. The embedded computing device 1 00 claims en address 
by randomly generating an address In the reserved range and then making 
an ARP request to see if anyone else has already claimed that address, 
AutoiP systems will continually check for the presence of a DHCP server so 

1 6 that If one should ever coma online, ail the AutoiP devices will attempt to 
switch thetr IP addresses to one provided by the DHCP server. This allows 
a network to operate in isolation, be connected to the internet with DHCP 
support and then to foe returned to Isolation. This type of scenario will be 
common in homes that use dial-up access. 

20 UPnP implements a peer discovery mechanism that uses the Simple 

Service Discovery Protocol (SSDP) for discovery of devices on IP networks. 
SSDP is based on profiles. A single Identifier specifies a profile that defines 
a contract between the client and UPnP Service {e.g., operational functions 
provided by the embedded computing device). By Identifying itself with 

25 the profile, the UPnP Service advertises compliance with the associated 
contract. 
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Using a single identifier mates it possible to implement an extremely simple 
discovery system. Clients send out a User Datagram Protocol (UDPJ 
multicast packet containing the identifier of the desired UPnP Service on 
some standard channel, UPoP Services listen on the standard channel, 
5 read the request, see whether they provide the UPnP Service, and respond 
if so, 

UPnP also provides a Directories mechanism to allow discovery to 
scale - to the entire Internet if needed. When present, & directory will read 
all incoming service requests and respond to them itself. This requires that 

10 all UPnP Services the embedded computing device 300} register with 
the directory so th&t the directory is able to properly answer on their 
behalf. The directory is also responsible for communicating with other 
directories in order to determine whether the UPnP Service is available 
within the local network, the WAN and potentially the Internet. 

1 S To simplify the discovery pfoipcoh directories are treated as proxies. 

A proxy is a service that accepts requests and takes responsibility for 
finding the proper response. When a client comes online., It will perform 
discovery for the proxy. If the proxy is present, then the client will send ail 
future discovery requests to the proxy. If the proxy isn't present., then the 

20 client will send ail discovery requests to the reserved discovery multicast 
channel. Regardless of the presence of a proxy, the client's request format- 
end procedures will always be the same. The only difference will be the 
address to which the client sends its requests. For UPnP Services,, the 
difference between a pmxied and unproxied network is their need to 

25 answer discovery requests. On a proxied network, UPnP Services need do 
nothing once they have registered with the proxy. On an unproxied 
network, they answer discovery requests directly . 
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SSDP uses the UDP- and Transmission Control Protocol {TCP}-based 
Hypt.ertext Transport Protocol iHTTP) to provide for service discovery. 
SSDP uses a Uniform Resource identifier fURl'S to represent the service and 
the OPTIONS method to provide for discovery, SSDP also will provide 
5 support for proxies, These proxies, which are really just fronts for 

directories,, redirect discovery requests to themselves. It is the proxy's Job 
to collect announce requests in order to determine what UPnP Services are 
available as weii as to communicate with other proxies in order to provide 
for scalable service discovery, 

10 The discovery process returns only the basic information needed to 

connect to the embedded computing device. Once a WnP Service has 
discovered its peers, the UPnP Service often needs to find out more 
Information In order to work best with them. The description process 
returns a schema providing descriptive data about the UPnP Service. 

1 5 A schema Is a structured data definition that defines a set of 

structured values that provide descriptive information about a UPnP 
Service. UPnP ases the Extensible Markup language {XMU for schema, 
because XML's ^describing structured data format provides the level of 
expressiveness and extensibility needed by a universal scheme end data 

20 format. 

Accordingly, UPnP supports automatic network introduction,, 
meaning that devices and their related WnP Services have the ability to be 
self-describing and allow automatic configuration. When a device is 
plugged into the computer network, the device automatically configures 
25 itself and acquires a TCP/IP address. The device then announces its 

presence to other devices already on the network using a simple discovery 
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protocol based on the Internet HTTP protocol and is immediately ready to 
share lis UPnP Services with any device that requests them. 

With UPnP, device developers are not required to develop specific 
device drivers to operate under UPnP, The task of preparing a device for 
5 operation in this network environment thus is fairly simple. Moreover, in 
configured networks, dynamic detection allows an operating system to 
immediately begin using added devices or stop using removed devices 
without rebooting, 

UPnP Devices support automatic discovery, identification., and 

10 configuration to achieve interoperability in the home environment, but must 
also operate correctly in a managed corporate network. Devices can be 
networked instead of being attached directly to a PC, and devices ere alt 
autonomous citizens on the network, able to talk with each other and 
exchange information. UPnP provides a unified way of performing 

1 5 directory services with automatic configuration. Capability for simple 

discovery mechanism used in the home environment provides the ability for 
any device to become a node on the global Internet. Additionally, directory 
services can be leveraged if they are available in the corporate 
environment, 

20 UPnP provides a common set of interfaces for accessing devices and 

UPnP Services, enabling the operational unification of diverse media types. 
Communications protocols for Universal Plug and Play are based on 
industry standards, especially key Internet standards such as TCP/IP, 
HTML, XML, HTTP, ONS, LDAP, and others. Individual implementations 

26 for particular networks and buses are built on established protocols. 

As shown in Figure 25, the software architecture 920 of the 
embedded computing device 900 {figure 24) includes the following 
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software c xfe no jules I , I *p < me t Up ^ ' de\ c i urn lions 92: simple 
discovery 924.. Hypertext Transport Protocol (HTTP) 925, Transmission 
Control Protocol/internet Protocol {TCP/IP) stack 928., Dynamic Host 
Configuration Protocol (DHCP) with AutoiP extension 928, Domain Noma 
5 System (DNS) with Multicast DNS extension 030, and physical media 910 
lalso shown in Figure 24). The device functions 922 is a software code 
module to implement the device's functionality. For example, where the 
embedded computing device is a VCR, the device functions code can 
include code to implement start, stop, pause, record and other functions 

10 that the VCR can perform, 

The simple discovery 924 is a software code module (about 4 
Kbytes) that implements a simple discovery procedure (described below) 
for automatic network introduction under the UPnP protocol. 

The simple discovery procedure additionally provides an Extensible 

15 Markup Language (XML) format device description, which is downloaded to 
clients that access the device to allow activation of device functionality 
from the client XML is a textual, tag-based markup language, if was 
originally designed to be the "Webby" simplification of SGML (Standard 
Generalized Markup Language), and is therefore intended to be used to 

20 create "vocabularies" of tags that can be used to apply semantic markup to 
documents., such as who the author was,, what constitutes a paragraph 
(sarnsmically, not from a display point of view), when the author last bad 
breakfast, and so on. (for more Information, see A. Layman, E, Jung, E. 
Malar, BO Thompson, J. Paoii, J. Tigua, N. H. Mikuia, S. Do Rose., XML- 

25 Data, IV 30 Note 05 Jan 1 998.) In the context of UPnP, XML is used to 
provide the description of UPnP Services and capabilities of the embedded 
computing device. The embedded computing device makes its features 
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visible to clients by providing ?ts XML device description, which the client 
can use to activate device functions 922, For example, if the device Is a 
earners, the client's browser can direct the camera to zoom in/out or adjyst 

i 11 f <fv1t 

6 The XML device description can provide links (via a uniform resource 

locator or URL address} to an accompanying XSL format style sheet. The 
XSL style sheets are used to present the data In different ways, La., the 
style sheets are applied to present different views of the same data. For 
example,, if the device contains a life system,, one style sheet can show the 
10 file selections; another shows the file sizes In some sort of diagram? yet 
another style sheet could make thumbnails of these image files, 

The HTTP 025 Is a software code modules (about 20 Kbytes) that 
implements the standard HTTP protocol, which is an open standard 
mechanism for client/server message-based communication, HTTP 
IS provides for proxysiig, content negotiation and security. (For more 

information, see FL Fielding, J. <3ettys, J, Mogul, H. Frystyk,. T, Berbers- 
! 2JTi£^ oj ~ \ FTP/I 1 , Ihl f IfC 2068 (January 

1997} J 

The TCP/IP stack 826 implements the standard TCP/IP networking 
20 protocols for communication on the computer network. The internet 
Protocol (IP! is the foundation protocol of the Internet. If defines how a 
single message Is sent from a source through zero or more routers to its 
I U3St>eeUJn h u 1 { I , - x jge iengti 

fragmentation, addressing, and routing concerns, The Transmission 
25 Control Protocol {TCP! is an IP-based protocol that provides support for the 
reliable, ordered delivery of messages over IP. Additionally,. User Datagram 
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Protocol (UDP) and internet Group Management Protocol mMP) multicast 
send/listen capability are included In the implementation. 

The AutolF 92.S is a software code module also used for automatic 
network introduction via AuloiP m the UPnP protocol AutoiP uses a 
5 predefined set of IP addresses and, when a device is connected to the 

network, it pings an address in this address space. If it gets no replies, the 
device assumes that the address is available and assigns It to itself. An IP 
Muitieesf Is a mechanism for sending a single massage to multiple 
recipients. IP multicasting is especially useful for discovery operations 

10 where one does not know exactly who has the information one seeks. In 
such cases, one can send a request to a reserved IP multicast address, 
Any UPnP Services that can provide the requested Information will also 
subscribe to the multicast request and thus be able to hear the information 
request and property respond < 

15 The DHCP 930 Is a software code module that implements the 

Dynamic Host Configuration Protocol (DHCP), which is a mechanism for 
providing devices with configuration information needed to access the 
Internet. The mechanism functions through the use of a multicast request 
for configuration information that is generally responded to with an IP 

20 address and DNS server location. Additional information can only be 
returned in the response. 

Figures 26 and 27 show processes 934, 940 per the UPnP protocol 
for automatic network introduction of the embedded computing device 900 
(Figure 24) into an ad hoc (where the device does not have a configured IP 

25 address) and a configured computer network environment, respectively. 
The automatic network introduction process establishes an appropriate 
configuration (e.g., with an IP address) of the embedded computing device 
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upon connection to a sewer computer on a computer network, so as to 
enable access to the device from a client. The processes 934,, 940 involve 
five phases: AutolP, announce, discovery., response to discovery, and 
device description. 

S At the announce phase, the embedded computing device 900 sends 

out a small multicast packet so that other devices can find it on the 
network. The multicast message packet essentially says, "I am here, i am, 
{say}, a camera, and you can reach me at this iP address or URL. " 

At the discovery phase, the embedded computing device 900 listens 

1 0 for a discovery packet, coming from a simple discovery client, i.e., the 

device announces itself, then listens for discovery. The discovery packet 
also is sent out by multicast. 

At response to discovery, the embedded computing device 900 
listens to the multicast address and then parses the information from a 

1 5 Simple Discovery request to decide if the request is for its kind of device, 
if so, the device 100 then sends back a response packet containing the 
following information: the IP address or URL where it can be reached; 
Identification of its own device type; and the discovery packet ID so the 
requesting client knows which request is being answered. 

20 At the AutolP phase,, the AutolP modulo 928 of the embedded 

computing device 900 uses a predefined set of IP addresses and, when the 
device is connected to the network, it pings an address in this address 
space, if no reply is received, the device 300 assumes that the address is 
available and assigns it to itself, 

25 Both the Announce and Discovery packets also contain a link or a 

URL to an XML file that is used by the embedded computing device at the 
device description phase to describe itself (i.e., its functionality). This XML 
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data contains all the facts about the device, XML can also have URLs that 
point to appropriate style sheets {XSL flies) that are used for optimal 
presentation. The XSi style sheets are used to present the data in 
different ways, i.e., the style sheets are applied to present different views 
5 of the same data. For example,, if the device contains a file system, one 
style sheet can show the file selections; another shows the file sizes in 
some sort of diagram; yet another style sheet couid make thumbnails of 
these image files. 
Exemplary Client 

1 0 With reference now to Figure 28, a client that accesses end uses the 

embedded computing device 900 over the computer network has an 
exemplary client software architecture 950, which includes software code 
modules for applications 952, Simple discovery 954, XML 955, LDAP 958, 
TCP/IP stack 958 and a network interface card {NIC} 980 that provides e 

1 5 physical connection to the computer network. The applications 852 is a 
software code module that provides a user interface features for locating 
desired devices |e«g., embedded computing device 900) and UPnP Services 
on the computer network, and also user interface features to Interact with 
the located device or UPnP Service. The applications 352 can include m 

20 Internet browser, such as the Microsoft Internet Explorer, that can present 
the XML device description in accordance with an associated XSL style 
sheet for interaction with the embedded computing device and activation 
of its operational functionality. 

Th i simple discovery 954 is a module that implements the above- 

25 described simple discovery per the UPnP protocol. The XML 955 is a 

module that processes the XML device description and XSL stylo sheets for 
presentation in the application's user Interface. The LDAP 956 implements 
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the standard LOAP directory protocol for name look-up > The TCP/IP stack 
958 implements the TCP/IP protocol for communications over the computer 
network,. 

* rn , *v v „ ^ ~nv > vT)ent 

§ Figure 29 illustrates a pervasive computing environment 1000,, such 

as may he installed in a home, office or public place, which includes a large 
number of embedded computing devices,- such as the illustrated device 900 
(Figure 24L The pervasive computing environment 1000 includes persona! 
computers 1002, 1004 (e.g., of the type shown in Figure 23} connected 

10 via a local area network (LAN) 1006, The PC 1002 is connected via a 
universal serial bus 1016 to a telephone modem 1010, XDSL interface 
101 1 or a cable modem 1012,- which in turn provide a connection with the 
computer network, e.g., the Internet. 

Various embedded computing devices also connect to the computer 

IS network via various network connections to the PCs 1002, 1004, These 
include an audio device 1014 |e,g„ speakers, radio tuner, microphone}, and 
printer 1015 which connect to the PC 1004 through a USB 1017. Also, a 
digital camera 1020,. a handheld PC CH/PQ 1021 and another personal 
computing device 1022 connect via an infrared port {IRQ A) 1024, which 

20 also attaches to the PC 1 004 through the USB 1 01 7. Also, lighting 

switches 1030 and like home appliances are connected via an A/C power 
line-based networking 1 032 to the PC 1 002. Further, a chain of IEEE 
1394 cables 1048 connect a digital TV 1040, DVD player 1041, digital 
video camcorder (DV/DVC) 1042., an audio device 1043 (e.g., CO 

25 player/recorder, radio receiver, amplifier, and hke audio system 

component),- and a game console 1044,. Devices, such as a portable 
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telephone 1 050 and remote control 1051, have a radio frequency network 
connection with the PC 1 004.. 

With their various inter-networked connections, the embedded 
computing devices are "visible" and accessible from a client device 950 
5 (Figure 29} also connected to the computer network, 
Seif-jnsrail And < on? \ Bridge 

With reference now to Figure 41, en instance of the U?r# bridge 
1 20 pgure 2) is automatically installed and configured for a peripheral 
device by operating system software of a host computing platform in 

1 0 accordance with a process 1 100 upon attaching or connecting the 

peripheral to the host. In an Implementation illustrated herein, this UPnP 
Bridge self-Install and configure process 11 00 is implemented as an 
enhancement of the plug-end-play process of the Microsoft Windows 
operating system running on a personal computer, 

IS As per the conventional plug-and-pIay feature of the Microsoft 

Windows operating system, the host computer's operating system detects 
at action 1102 as part of It hoot-up routine that any new peripheral devices 
have been attached to a peripheral device bus (e.g., the ISA,. EISA, PCS,, 
USB, serial or parallel ports,, etc.) of the host computer. Alternatively, this 

20 detecting of new peripheral devices can be done at any time during norma! 
operation of the host computer so as to detect "hot-plugging" peripheral 
devices that can he attached to the host computer while running. Upon 
detecting a new peripheral device has been added, the host computer's 
operating system proceeds to identify and install an appropriate device 

25 driver software for the host operating system to interact with and/or 

control the peripheral device as indicated at action 1 103. If the appropriate 
device driver is not already loaded on the computer, the operating system 
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prompts the user to insert a disk of like storage medium containing the 
device driver. Alternatively, the operating system can download the device 
driver from a server computer on a network. If unable to identify the 
appropriate device driver for the new peripheral, the operating system 
5 prompts the user to select or provide the device driver {e.g., from a disk 
provided by the peripheral manufacturer). 

The enhanced plug-end -play feature of the operating system 
additionally automatically installs an instance of a UPnP Bridge 1 20 f Rgure 
2} on the host computer at action 1 104 for use in adapting the peripheral 

1 0 for peer networking connectivity via the UPnP device control model over 
any networks connected to the host computer. The operating system 
configures this UPnP Bridge instance to expose the operational functions of 
the peripheral with an appropriate XML discovery and description data, As 
discussed above, any UPnP User Control Point thereafter can obtain the 

1 5 XML discovery and description data from the UPnP Bridge, and interact 
through the UPnP Bridge with the peripheral device as specified by the 
X#t data. Alternatively, where an appropriate UPnP Bridge instance or 
configuring XML data is not available on the host computer, the operating 
system can prompt the user to select and/or provide such from a peripheral 

20 manufacturer-provided disk or download. 

The host's operating system then continues to repeat the actions 
11 02-1 104 for any other new peripheral devices that have been attached 
to the host computer. 

Although illustrated with reference to the Microsoft Windows 

25 operating system and a personal computer as the host, this self-install and 
configuring of a peer networklng-to-host/'paripheral adapter also can be 
Implemented on various other host/peripheral computing platforms (such as 
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in a video game consoles, television set-top boxes., audio-video consoles, 
stc, which are structured as host computers which are extensible by 
connecting peripheral devices} so as to automatically provide peer 
networking upon attaching a new peripheral to such computing platforms, 
5 Having described and illustrated the principles of our invention with 

reference to an illustrated embodiment it will be recognized that the 
Illustrated embodiment can foe modified in arrangement end detail without 
departing from such principles, it should be understood that the programs, 
processes, or methods described herein are not related or limited to any 

1 0 particular type of computer apparatus, unless indicated otherwise. Various 
types of general purpose or specialized computer apparatus may be used 
with or perform operations in accordance with the teachings described 
herein. Elements of the Illustrated embodiment shown in software may be 
implemented in hardware and vice versa. 

tS in view of the many possible embodiments to which the principles of 

our invention may he applied, it shouid be recognised that the detailed 
embodiments are illustrative only and should not be taken as limiting the 
scope of our invention. Rather, we claim as our invention all such 
embodiments as may come within the scope and spirit of the following 

20 claims and equivalents thereto. 
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1 . A distributed computing network having st least one 
computing device, the distributed computing network comprising: 

§ a plurality of peer networking computing devices communicating 

according to a peer networking connectivity model having user control 
points and controlled devices; 

at least some of said peer networking computing devices being 
programmed to operate as controlled devices exposing at least one 

1 0 operational function to control from others of said peer networking 
computing devices; 

at least some of said peer networking computing devices being 
programmed to operate as user control points whereat a user interface is 
presented for interaction by a user to control said controlled devices; 

I B at least one of said peer networking computing devices being a host 

computing device having a general purpose operating system that provides 
at least one service exposed to programmatic control via an operating 
system application programming interface, said host computing device 
further being programmed to expose said at least one service as a 

20 controlled device In said poor networking connectivity model, 

2. The distributed computing network of claim 1 further 
comprising a publishing adapter program running on said host computing 
device and operating to convert device control communications from said 

25 st least some peer networking computing devices operating as user control 
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points into calls via the operating system application programming interface 
fore 



3 The d spi t ig network of claim 2 wherein the 

publishing adapter program acta as a peer networking addressable device ir 
the distributed network to which said at ieast some peer networking 
computing devices operating as user control points can establish a 

«et^ 1 id - ~ > 



4. The distributed computing network of claim 2 \ 
publishing adapter program supports discovery by said at least some peer 
networking computing devices operating as user control points of 
operational functions of said at least one service by supplying a structured 
IS data message defining control of said operational functions in response to a 
request according to the peer networking connectivity model from said at 
least some peer networking computing devices operating as user control 



20 5. The distributed computing network of claim 4 wherein the 

publishing adapter program supports control of said operational functions 
by said at least some peer networking computing devices operating as user 
control points by converting communications from said at least some peer 
networking computing devices operating as user control points as defined 

25 by the structured data message into communications via the operating 

eg terfare expoM k the t sast one s vice 
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for controlling said operational functions of said at feast one peripheral 
device. 

8, A genera! purpose computer comprising: 
5 a processor, data storage., data input/output, and networking 

hardware resources; 

a general purpose operating system controlling the allocation and 
usage of the hardware resources; 

a plurality of services of the general purpose operating system 
10 operating to perform specific system functions to support application 
programs run on the computer; 

an application programming interface exposing the services to 
control from the application programs; 

a networking adapter and network operating software module for 
1 5 peer networking with peer devices; and 

a service rerouting publisher software module operating to convert 
between communications according to a peer networking connectivity- 
based device control protocol and communications via the application 
programming interface with the services for exposing the services to 
20 control from the peer devices using the peer networking connectivity- based 
device control protocol, 

7. The general purpose computer of claim 8 wherein said service 
remoting publisher software module further converts between 
26 communications according to ssid protocol and application programming 
interface for aiso supporting contra! fey the service of the peer devices 
using the peer networking connectivity-based device control protocol 
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8, in a computing network, a method of interoperating between 
peer networking devices using a networking device control protocol and a 
service of a general purpose operating system on a computer exposed via 

5 an application programming interface, the method comprising: 

providing a peer networking address for addressing a peripheral 
devsce; 

in response to a request according to the networking device control 
protocol from a peer networking device specifying the peer networking 
10 address, establishing a connection with the peer networking device; and 
in response to invocation of an operational function of the service 
according to the networking device control protocol from the peer 
networking device on the connection, converting the invocation into a 
service invocation through the application programming interface to the 
1 5 service. 

9, The method of claim S further comprising: 

in response to a discovery request according to the networking 
device control protocol from the peer networking device., providing a 
20 structured data message defining invocation of at least one operational 

function of the service according to the networking device control protocol, 

1 0, The method of claim 9 wherein said invocation includes 
exchanging a set of further structured data format messages. 

25 

11, A computer-readable data-carrying medium having a software 
program encoded thereon and executable on a general purpose computer in 
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a distributed network of peer computing devices for remotely exposing 
system f unctions of an operating system service available via an 
application programming interface to remote control via a device control 
protocol using peer networking connectivity, the device control protocol 
5 defining communications between user control point nodes and controlled 
device nodes in a distributed network of computing devices permitting 
control of operational functions and services of the controlled device nodes 
from the user control point nodes, the software program comprising: 
a program module for creating a peer-networking addressable 

1 0 controlled device node exposing the system function of the service 
available through the application programming Interface; and 

a program module for converting communications/to the peer- 
networking addressable controlled device node in the first device control 
protocol from a peer computing device to the general purpose computer 

1 5 Into invocation of the service via the application programming interface, 

1 2, The computer-readable data-carrying medium of claim 1 1 
further comprising: 

a program module for creating a peer-networking addressable user 
20 control point node; and 

a program module for converting service invocations via the 
application programming interface on the general purpose computer Into 
communications in the first device control protocol from the peer- 
networking addressable user control point node to control operational 
2o functions or services of another controlled device node. 
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1 3. The computer-readable data*carrymg medium of claim 1 1 
further comprising a program module for providing structured data defining 
communications in the first device control protocol for invoking the system 
function of the service to user control points via the first device control 

S protocol. 

1 4. A computer-readable data-carrying medium having a software 
program encoded thereon and executable on a computer in a distributed 
network of peer computing devices for device control of an operating 

1 0 system service on the computer, the software program comprising: 

a service remoter code acting to control functionality of the service 
via an application programming interface associated with the service; 

peer networking device control protocol code acting to interconnect 
with the peer computing devices to exchange device control 
1 6 communication for control of peer controlled devices by peer user control 
devices according to a peer networking device control protocol; and 

a peer networking device control protocol publishing service code 
communicating with the peer computing devices via the peer networking 
device control protocol code and with the service via the service remoter 
20 code and acting to expose the service's functionality as a peer controlled 
device according to the peer networking device control protocol to the peer 
computing devices to enable control of the peripheral device from the peer 
computing devices, 

25 1 5. A computer-readable data-carrying medium Having a software 

program encoded thereon and executable on a computing device in a 
distributed network of peer computing devices Interoperable according to a 
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peer networking device control protocol by which a user control point 
module on a controlling device operationally controls a controlled device, 
the software program comprising; 

peer networking connectivity services interacting with the peer 
5 computing devices using the peer networking device control protocol; 

peer networking connectivity publishing code converting the 
interaction with the peer computing devices using the peer networking 
device control protocol to operating system service invocations according 
to an operating system application programming interface; and 
1 0 an application programming interface operationally invoking a system 

function provided by an operating system service with the invocations, 

1 6. A computer-readable data-carrying medium having a software 
program encoded thereon and executable on a computing device In a 
1 5 distributed network of peer computing devices, the software program 
comprising: 

a controlled device operating system service remoter node operating 
as an addressable peer controlled device according to a peer networking 
device control^ protocol defmmg communications between peer controlling 
20 devices and peer controlled devices permitting control of the peer 

controlled devices by the peer controlling devices on a peer networking 
basis; 

code in the controlled device operating system service remoter node 
operating responsive to control communications from a peer controlling 
25 device according to the peer networking device control protocol to control 
an operating system service vis an operating system application 
programming interface. 
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1 7. A computer In a distributed computing network having a 
plurality of peer networking connected computing devices imeroperating 
according to 3 peer networking device control model in which the peer 
5 networking connected computing devices run user control point modules 
and controlled device modules, where the user control point modules 
support user interaction to control operations! functions supported by the 
controlled device modules,, the computer having a general purpose 
operating system software loaded thereon comprising: 
1 0 a peer networking module for networking with the peer networking 

connected computing devices; 

a controlled device module supporting control from the user control 
point modules on the peer networking connected computing devices, and 
controlling services of the computer's general purpose operating system via 
1$ en operating system application programming interface. 
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<?xml version~"1.0"?> 

<scpd xm?ris^ ;; x--scherna:scpcl!-schema,xnif> 
service StateTabfe> 
<siateVadabte> 
<name>QurrenlChmmi<fmme> 
<dataTyp8>number</dataTyp6t> 
<a ilowed Va fueRange> 
«mintmum>Q</minimum> 
<maximuffi>5g</nm1murn> 
<step>1</step> 
</a!lowedValueRange> 
</&taieVababfe> 
</$erviceSta!eTabte> 



<act!0!ilist> 
<acbon> 

<name>ChanneiUp<toame> 
</aetbn> 

<acdon> 

<naroe>CharmelDown<name> 
<f&Gi\Qn> 

<aefei> 

<name>8etCbannei</name> 
<a<gumerrt> 

<ra re a i 

<re)atedStateVariabte> 
currantChannei 
</ra!atedStateVariab(e> 
■</argument> 
</action> 
</acoonList> 
</scpd> 
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<?xmi versson™"1 .0"?> 
•-Schema name~"upnp„scpdf 

xmfns^ i \irn:schenias-f:iicrosoft--com:xml-clata'' 

xnnrjs;dt™ ,! urn-.sohernas-microsoft-com:datatypes [, > 

<!---- Common Elements and Attributes ~~> 

<EiementType name^'name" ccmtent-nexlOniy" dt^pe^'string" /> 
<!-- Service State Table -->' 

<ESementType name- a rninimum s contenl^'texiOnly" dt;type-"number !> /> 
<EierneniType name^'maximum" oontent-^extOnly" dtlype="n umber" /> 
<ElementType name~*slep" content""taxtOniy" df typ^'number" i> 

<EiemeniType name \ > leh ciosed w > 

<e!ement type~^msnsrnum !i /> 

<etement type™"max?mum" /> 

<aiement type~"siep i; minOeeufS~"0" /> 
</EiementType> 

<EtementType name~ ,: a!iowedValue" content~"lextO«iy B /> 

<BamentType name~ !, ajfGwedValu©Lisf content-^aliOniy" model""dosed"> 

elem d m>Occurs- !! 1 roaxOccufs-'*" /> 

</EiameniType> 

<EtementType na rne-"d ataType" content- 'iextOn i f d > . lype~"string" i> 

i imeni ype same st< - c iteni- itOniy m* iei "cl ad" 
<8lement type~"name >! t> 
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oiemen* type~ M dataType" /> 

<group rninOccurs^O" maxOecurs~"r ofder« M one w > 
«efen i s i aRange" /> 

<ele«leiittype~ ,! allowe{IVafue!Jsf /> 

</group> 
</T:iementType> 



<ElementType narr^^tevH^StateTabte" eon(£nt~"eltOnly !! model~"closad <! > 

<etement type^siateVwfetote" roinOeeurs-'T' maxOccurs«"* B /> 
«/Ef©rnentType> 



< Action List • 

<EtementType nane- ' i t\ << sriabte* oontent»*te)dOniy" dtlype-Ctdng* /> 

<E!ementType nama~"argumem" contentions model~"dosed"> 

<el^ertt.iype*"nanie* f> 

<etement type-'YelatsdStateYadabfe" /> 
</EieroentType> 

<ElementType rrame=*action fl cont®ai~*e5tOniy" mode!-"ciosed*> 
<element iype*"name* /> 

^element type^'argument" mioOccurs^O" maxOecurs^*" /> 
</ESemeniType> 

<ElemerrtType name*"actbnUsf conle < - 'lOih nxHM~"do^T> 
scf )->in< }ccufs~"0 5> maxOocufs- '*" /> 

</EtementType> 
Rod I an enf 

«£tementType name^'dcper content^'ellOnl/' modei«"ciosed M > 
<eleraenf type- di tatert able" /> 
<el n en yp t 1 $ ioi 1 s 
</ElementType> 
</Schema> 
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/ 
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object 

uuid(<foo>} 1 

dual, 

pointer defaultfunique) 
I 

I 

fipropget, id(OISPU.^UPNPD£V!C£„P£S€RiPT!OHDOCUMEHT) ( 
.^Ipstringf returns the document from which the prepenses of this device are 
bosng read";} 

HRESUL T D nptso ^> s ' O 

IUPNO ocument ** ppuddDocument}; 

purpose: returns the document from which the properties of this device are 
being read, 

pe> tn document 

i f ice is being read This must he freed when no 

longer needed. 

return values: S OK, ppuddDocument is a refemee to the device's 
description document. 

p opgei d(DISPID UPNPOEVICE JSROOTDEVICE), 
helpstringf 'denotes whether the physical location information of this device can 
be sef )1 

HRESULT sRootO« pvarb) 

paratn. , < \ the address of a VARIANT BOOL that Will receive the 
value of VARIANT. TRUE If the current device is the topmost device in the device 
free, and will re. ? > VARIANT FALSE otherwise. 

ei;.;?n vsioes- S...OK. vs?b is * >. s > . 

U > - s>\ce is a rootde ce, calls Roof.Oevlcr or i < 5 i I * ? il 
return NULL 



[propget id(DISP!D.UPNPOEViCE...ROOT) J 
heios, mu\ re^m« the top -levee s I e device tree"?] 
H RE SUIT fTx r V*re h< * 'e^ v ' » « > > 

purpose: returns the top device In the device free 
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pars this eterstotheh - evice 

fo uff o, jeu<\~fre© I <*» see dc 4 . c<- ^ * ^ 

If the current vi - c root device this method will set *ppudDeviceRoat to null 
and return S. FALSE 

return values: SJ3K, *ppudDeviceRoof contains a reference to the root 
device. S m f ALSE, the current device is the root device, *ppudDeviceRoot is null. 

lpropgetJd{DiSPiOJjPHPDEVlCE„FARE^TK 

! « * < * * relva!] > V< ^ we ** i * >,en*> 

patam< * ^ Ar it the device has a parent sic 

the address of a iUPNPDevice object wiech can descnoe the parent. This must be 
released when no longer needed. If the device has no parent (it is a "root" device), 

! , ! 1 

return values: S..OR, ppudDevloePareni contains a reference to the device's 
parent. S_FAL.SE, the current device is the root device, which has no parent. 
*ppudDevlceRoet is null 

[propget, idCDISPIDJjPMPDEVICE^CHILDREN), 
hefpstringfretums a collection of the children of the cunenl device")) 
HRESULT Chsldrentlout, retval] iUPNPDevices ** ppudChiidren): 

parameters: ppudChsklren, On retun j , ? 

lUPNPDevi « lean t v Phis' must I 

released when no longer needed if ihe device has no ohshj-cn ;n>s method will 
return a collection object with a length of zero. 

return values- S OK. ppudChiidren contains a list of the device's children. 

[propget, id{DISP!DJjPNPDEVlCEJJDN), 
heipetringf returns the UDN of the device^}] 
HRESULT UniqueDevleeNarneilouf retval] BSTR * pbstrUDN), 

mist < s: pbstrUDN, C un I cental \ it of a n 
v • * ! - p 3 < | to ' H i e I \ I m. Ut N 

Is globally unique screes nil devices ■■ no two devices will ever have the same UDN. 
This value most be freed when no longer needed. 

return values: S OK pbstrUDN contains the UDN of the device 
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Ipropget, i d ( D I S P I OJJ P N P D E VIC EJ3 I SPLAYN AM E ) , 

iisplay name o the devkxftg 
I RESUI ] HsplayN i r< ([o ,l ret 0 BSTR * pbstrO spiavN j 

parameters; pbsir Display Name, On return, this contains the address of the 
device's display name. This value must be freed when no Ion jer need ad . If the 
device does not specify a display name, this parameter will be set to null. 

return values: SJ3K, bstrDisplayhiame cor; s > c >ia :ma of the 
device, n = I 8 ' SI ^ t. ue >1k u -< 

1 5 null 

nco si I i~ ueM MoIhwUv^ ? < diNe{a\ < *e 

\ ons shoui I use UniqueDeviceNameO to determine If two device objects 
refer to the same device. 

lpn?pget,Id<Dt$PIO„UPHPD£VICE_CANSETD!SPLAYNAME) s 
helpstr r> ocatlon reformatio? ofthisdev 

be set"}] 

HRESULT Can8et0ispiayName{fput, refvaij VARIANT... BOOL * pvarh}; 

parameters: pvarb, the address of a VARIANT ..BOOL, This is true (J«Q) on 
return when the device's display name can be set (via SetDisplayName) 
return values: SJ3K varb is set to the appropriate value 

fid(D!SPlD.UPNPDEVfGE SETDISPLAYNAME), 
heipstringfsets the display name on the device**^ 
HRESUL i 8 \ < -V i bSTi^bsfrDlsplayName); 

\ i u o - i the d^Vko's Osbouy rj p ^ 

return values: SjOK, varb is set to the appropriate value, 
note; On success, this method sets the display name used by a device. 
Note that thus method cturges i. j m u < s> *nc cevr:e st^lf rot s only on 
the local object. This will block while the name is being set. 
Additionally, this change will be made on the device alone, and will not be reflected 
in the current device object. After a successful call to this metmxh Display-Name 
will continue to return the 'old' value.]. To read the device's cur rani name, the caller 
must re-load , - < , * e notion 

[propget, 5d(Di$PID. UPNPDEVlGE.D£VIC£TYPE} t 
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heipsthnqfreiums the device type URf)| 
HRESULT Typefloul, retvaij BSTR * phstrType); 

in return , this co ' i t 1 

»« , v This value must be freed when no ienget 

needed. 

return values. S OK, bstrType contains the type URI of the device, and must be 
freed when no longer needed. 

(propget idCDISPiDJjPNPDEViCE^SERVICES}, 
t I h t ' < v t k the ,e I . or services expose by the dev;ce !! }] 
HRESULT Servicesljout, reiva!'] lUPUPServices ppusSer vices): 

parameters ppirsServlces, On return, this is the address t i a newiy-ereated 
iUPNPServices collection that can enumerate the services exposed by the device. 
This must be released when no longer needed, if the device exposes no services, this 
method will return a coi - < > * with a length of zero. 

return values; S...OK, pusServiees contains a list of the device's children, 

[propget, fd(D3SPID_yPNPDEVICE_SERVIC£IDENTIFIER|i 

j I BSTR * pbstrServfoelD ) 

parent ! ^ newty- 

s \ contents of the d« f 5 i < <! > 

levies specifies ot s value n st be freed when no longer needed. If the device 
does i specify a Sefvlcsidentifier value, this psrametsr will he set to null 

return value: S OK, bstrServSoeSO contains the service identifier of the device. 

n M i i t , s > s f \ 

i k i 1 ' 

hots ha\ 38S Any 

device will either have a list of services or a Serviceidentmer, but not both. 

pd(DISPIOJjPNPDEV]CEOESCRIPT!ON.LOADSrviAllJCON}, 
heipshingf loads a small ;btiebaes;sed; icon representing the device, encoded in the 
specified format"}] 

RESULT L > ! BSTR bstrEncodingFomiat. 

out reiva!] 58TR 1 > nl Rt); 
parameters; 
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bsfrEncodingFe-miat. A string containing the mime-type representing the desired 
* tog format of ? scon, pi cc ri O x pb6trlcc UR contains a 

i \V v H - * s stung representing the URL fsom which trie scon can be loaded. 
This string must be freed when no longer needed. 

return values; SjOK, *pbsbiconURt contains a reference to an Icon, 
encoded in the desired encoding format 

[id{DiSPID_UPNPOEVICEDeSCRIPTION_LOADICON), 

helpstrlngf loads a standard-steed Icon representing the device, encoded In the 

HRESULT Loadlconflin] BSTR bstrEncodlngFormat, 
[out retvalj BSTR * pbsfrteonURL); 

parameters: bstrEncodlngFormat, A string containing the mime-type 
»g th« esired encoding format of the icon. pbstrleonURL, On return, 
*pbstrlconURI contains a new!* ? URI from whicl 

the icon can be loaded. This string must be freed when no longer needed. 

return values: SJDK, *phsttlconORL contains a reference to an icon, 
encoded in the desired encoding format. 

[propget, id(OJSPID_UPNPDEVICEDESCR!PT10N_PRESENTATIONURL), 
» 1 . t $ nn^sentat on URL to a web page that can control the 
device'}] 

HRESULT PresentationURLCIout, retvalj BSTR * pbstrURL), 

parameters; pbstrURL, on return, the address of a newly-allocated string 

containing the web~page~hased control URL, if the device did not specify a 

presentation URL, an empy string C) mil be returned. 

fefurn valucs:S _ OK, bstrURL contains a newly-allocated URL that must be 

freed when no longer needed. S FALSE, the device does not have a presentation 

URL. pfastrURL is set to null. 

fpropget, id(DISPID_UPNPOEVlCEDESCRIPTION_PHYSICALLOCA"nON), 

' , 5 < j J , - , - J 

HRESUL1 PhysicalLocation(foui , I j pup!) 

parameters: pupi on return, the address of a newiy~a; located 
UPNPPropertyBag object which contains information about the device's physical 
location 

return values 
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S.OK n; >mains a ■< > t < \ " sat the cailef 1 1 

is no longer needed, 

note: if the object does not provide any description information, an empy 
props rty bag will be returned See SetPhysk t!L - stion tot 3 listing of defined 
values in a physical location property beg, 

fpropget, 

id{DiSPI0_„UPNPDEVICEDESCR!PTION„CANSETPHySICALLOCATION) J 

helpstflngf denotes whether the physical location information of this device can 
be set}] 

HRESULT C3nS8tPhys:caLocation(|ouf 5 refvat] VARIANTBOQl * pvarb); 
parameters: pvarb the address of a VARIANT . BOO. I us is tn e i ~G) on 
return when the device's physical location can be set (via SetPhysical Location) 
return values: S„ OK varb is set to the appropriate value 

pd{D]SPiD_UPNPDEVIOEDESCRiPTiON_SETPHYS!CAtLOCATION)j 
helpstringfwrites a set of properties describing the device's physical location to 

ti i ;vi 

H RESU IT SetPhysicalLocation {[in] iUPNPProperiySag * pypl); 

parameters; pupl A UPNPPropertySag object which contains the name* 
value pairs representing the device's current location- the function will not free the 
object 

return values: S_OK he device has been updated with the supplied 
physical location information 

iota ihi following are standa i values in the \ \ property bag 

<ouifiy ■> r wng, mom „ -de These 

values can be used programmaticaity to Implement sorting os * 
has I n the device's location. Additionally the prop; \ >< blowing 

value do ptk /nich contains a « t ce's 

location which does not have programattic significance. Additionally, the physical 
location update will he made on the device alone, and will not be reflected in the 
current device object After a successful call to this method, PhysicaiLocation will 
continue io return the 'old* value. To read the device's current name, the caller 
must re b n - s description . 

} 
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[propget, id{D!SPlD_UPNP0EVICEDESCRtPTION„PRODUCTNAME) t 
helpsfnngfa 1 p r/al « o rsg \ x< the \ oduoi name")] 
H RESULT ProductNamegout, retvai] BSTR * pbstr}; 

parameters; pbstr on return, the address of a newly-allocated string 
containing the product name of the device. 

return values: 8jOK pbstr contains a newiy-a 
be freed when no longer needed. 

[propget, id(DlSPID UPNPDEVICEDESCRIPTION ..DESCRIPTION), 
helpsthngfdispSayable summary of the device's function 11 )! 
HRESULT Descnption0Jout, retvai] BSTR * pfestrl; 

parameters: pbstr on return, the address of a ne * I sti ng 

containing a short description of the device meaningful to the user. 

return values: S„OK pbstr contains a newly-allocated string that must 
be freed when v * g 

ipropgat.. ld{DISPID„UPNPDEVtC£DESCRIPTiON_MOOELNAME), 
oea ^ npfdispiavabie model mm")} 
HRESULT ModelNametfout, relval] BSTR * pbstr); 

parameters: pbstr on return, the address of a newly- allocated string 

* « k-we ot the device, 

return values: SJ3K pbstr contains a newly-allocated string that must 
be freed when no longer needed. 

[propget, sd(DISPfD_UPHPDEV!CEOESCRiPTION m SERiALNUMBER) ( 

* s x * 5 > c-cnal number")] 
HRESULT SenaiNumher(|oyt. retvalj BSTR * pbstr); 

parameters: pbstr on return, the address of a newly-allocated string 
containing the manufacturer's serial number of the device. 

return values: SJOK pbstr oonta is i newly s ng hat m sf 

no lo Kjer needed 

note: a device's serial number is not guaranteed to he globally unique. The 
DeviceUniqueHame should always be used to distinguish devices. 

sf id{DiSPIDJJPNP£ >^ I I OH MANUFACTURERNAME) 

heipslnngfdisplayahle manufacturer name''}] 

it 'OtvallBSTR^ pb h) 

parameters 
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pbstr, on return, the address of a newly-allocated string containing the name of the 
4e v ice's man ufactuer, 

return values; S...OK, pbstr contains a newh at must he 

freed when no longer needed, 

fpropget. id{DISPID„UPNPDEV{CEDESCR!PTION„yANUFACTURERURl), 

)R « t < \mi ers website")! 
HRESULT ManufecturerURL([out, retvalj BSTR * pbstr); 

parameters; pbstr, on return, the add - ss o* 5 s ^ wiy -* ! s - 1 sited siring 
containing the URL of the manufacturer's website. 

return values: S .OK, pbstr contains a newly-allocated string that must be 
freed when no longer needed. 

[propget, id(DISPiO„UPNPDEV!CeDESCRIPT}ON_MODELNAME), 
he!psthngfdl8f>layabte model name")! 
HRESULT MoctelNamedout, refvall BSTR * pbstr); 

parameters; pbstr, on return, the address of a newly-allocated string 
containing the manufactuer's model name for the device. 

return values; S..OK, pbstr contains a newly-allocated string that must ha 
freed when no longer needed. 

fpropget, id(D?SPID.UPNPOEVlCEDESCRIPTION„SUPPORTLfST) ! 
he spsl' no > < an ')} 

HRESUI ?ival]8S7E ^bstf) 

. parameters: pbstr, on return, the address of a newly ~aiiocated : multi-line 
string containing phone numbers and other Information that can guide the user to 
* ) { i < * 1 r 9c' needed 

return values: S OK, pbstr contains a newly-allocated string, that must be 
freed when no longer needed. 

|propgef ( id{DISPID m UPNPDEV]CEDESCRIF J TION..FAaUST) ( 
"hoipstdngiTAQ access display information")] 
HRESULT FAQLisf([out, retvalj BSTR * pbstr): 

pasametem pbstr or n~fcrr\ aad'O^s cf a rev, n u-t> I m. 

format le the user v* th UR it t lich 

nay be located. 

return values: S OK, pbstr contains a newsy-allocated string that must be 
freed when no longer needed. 
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[propget, id<DiSPiD UPNPDEVICEDESCRfPTiONJJPDAmiST), 

heips?nng( : ^forni3iion expiating where the user can update the device's 
firmware")} 

HRESULT Updatelist([out retvall RSTR * pbstr); 

parameters; pbstr. on return, the address of a newly-allocated, multi-fee 
«= h » »g con! ) s nation and URLs from which the user can download updates 
for the device's firmware. 

return values: SJM, pbstr contains a newly- allocated string that must be 
freea wners no longer needed. 
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i 

object, 

uuld(FDBC0C?3^BDA34C56-AC4F..F2P96FDADaaC), 
dual, 

hefpslnngi'lUPNPDevioes interface"), 
pointer jtefault(uaique) 

lUPNPPropertvBag 
( 

[propgei id(DSSPID_UPNP_PROPERTYBAG„ READ), 
hefpsiringCreads a value from the property bag")| 

HRESULT Readffjnj BSTR-bstifsiarne. |out. retvalj VARIANT * pvsrResultv 
■si i f f ase s ignored 

pvarResulfvalue of the property, if the aropertv doeae not exist, this is of type 
VT„EMPTY 

return values: SJ3K, the value was found in the property bag, and returned 
in pvarResult, S FALSE, there was no value with the given name in the property 
bag, *pvarResult is of type VT.EMPTY 

fpropgat, id{DiSWDJUPNP_PR0PEHTYBA6„WR!TE), 
helostringfwrites a value to the property bag")] 
HRESULT Wnte(|in| BSTR bstrName, [in] VARIANT * pvarValue); 

; arametors bstrName, name of the p? >p« h, < m te s a; ( is preserved 
when writing. T he supplied value will replace any other values of the same name, 
even if they differ in case. pvarValue, value of the property to write, 

return values: S...OK, the value was written to the property bag, replacing the 
« * " this property, if it existed, 

Ipropget, id(DISPlD„UPNP„PROPERTyBAG_.DELETE}, 

e- < k j ! > nag") 

KM, ' \ \ , '« 1 SIR 

parameters: bstrName, name of the value to remove from the property gab. 
case is ignored when finding a value to remove, 

return values: S OK. the value has beers removed from the property hag. 
S_ FALSE, the value was not found in rise property bag. 
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object, 

uuid{A2950 1 9C-DC86~47OD-90DC-?FE9 1 8A1 A844) : 
dual 

helpstringCIUPNPSea'sce Interface"}.. 

palate it i 

I 

intsrfgc-- jui ni ; -wrvsce ■ IDispatch 
I 

id(l }, h i Get! 'ropoftv"}] 

HRESl pe?ly{ 
pn| BSTR bstrPropertyName, 
|out f ratvai] VARIANT *pValue 
): 

[id^A neipsm fx n >: >1 r, >\*»Act>on 
HRESULT lnvokeAcHon( 
pn| BSTR bstrActlonName, 
[in} VARIANT saActlonArgs, 
[out, retval] long *piSiatus 

); 

(propget ld(3) lieio^ 
HRESULT DCFI( 
[out, retvaij BSTR *pVal 

i; 

Epropget id{4), 

heipstnrigfretiiim a manufacluer-defined extension property"}] 
HRESULT < jut ohmljVARI ^ , Vaine* 

parameters: pvarVaiueOn return, this variant is fifed with the value of the 
"extension" element. If none exists, pvarValue is set to VI EMPTY 

return valuer 1 OK \<*i\'* ue is set to the * mort S_FAt.SE 

novendoi extension element exists. pvarValue is VT EMPTY 
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object, 

yyid(FD8C0C73-BDA3^C66^AC4F-F2O96FDAD68C). 
dual, 

fteipstrin I cos Interface"), 

ps nt i s ; ! 

j 

interface lUPNPDevices ; IDispatch 

{ 

Ipropget, id{1), helpstnngfproperiy Counf)J 
H RESULT Count; 
[out, retvalj long *pVai 

); 

fpropqet ^{DSSPJD^MEWENUM), beiosiringf property NewEnum")! 

HRESULT „NewEnum{ 

|out. retval] LPUNKNGWN *pVai 



[proper «d< JJSPil) VALUb) "H <v ry iVrr"}] 

HRESULT !tem( 

pn] lonq I Index. 

[out, retvalj VARIANT *pVal 
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object, 

yuid{3F8C8E9e~9A?A-4DG8-8C41^FF31FA374958) ( 
dual 

helpstflng("!UPNPServlces Interface"), 

pointe f $ u ique) 

I 

interface iUPNPServices : IDispatch 

I 

[propget Sd(1), h^pstringC'properiy Count"}] 
HRESULT County 
(put, retvaQ long *pVaf 
)» 

[propget, id{DISPlD„NEWENUM), heipstrmgf property „NewEnum >i )| 

HRESULT NewEnum( 

{out, retvai] LPUNKNOWN *pVal 

); 

[propget klpSPiD VALUS ) t p operty item V 

HRESULT ltem( 

pnj Song Hndex, 

[out, retval] VARIANT *pVai 

):• 

I; 
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